| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
This adds support for an indexed instrumentation based profiling
format, which is just a small header and an on disk hash table. This
format will be used by clang's -fprofile-instr-use= for PGO.
llvm-svn: 206656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The option LLVM_ENABLE_SPHINX option enables the "docs-llvm-html",
"docs-llvm-man" targets but does not build them by default. The
following CMake options have been added that control what targets are
made available
SPHINX_OUTPUT_HTML
SPHINX_OUTPUT_MAN
If LLVM_BUILD_DOCS is enabled then the enabled docs-llvm-* targets will
be built by default and if ``make install`` is run then docs-llvm-html
and docs-llvm-man will be installed (tested on Linux only).
The add_sphinx_target function is in its own file so it can be included
by other projects that use Sphinx for their documentation.
Patch by Daniel Liew <daniel.liew@imperial.ac.uk>!
llvm-svn: 206655
|
| |
|
|
|
|
|
|
|
|
| |
Immutable DILineInfo doesn't bring any benefits and complicates
code. Also, use std::string instead of SmallString<16> for file
and function names - their length can vary significantly.
No functionality change.
llvm-svn: 206654
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While unnamed relocations are already cached in side tables in
ELFObjectWriter::RecordRelocation, symbols still need their fragments
updated to refer to the newly compressed fragment (even if that fragment
isn't big enough to fit the offset). Even though we only create
temporary symbols in debug info sections this comes up in 32 bit builds
where even temporary symbols in mergeable sections (such as debug_str)
have to be emitted as named symbols.
I tried a few other ways to do this but they all didn't work for various
reasons:
1) Canonicalize the MCSymbolData in RecordRelocation, nulling out the
Fragment (so it didn't have to be updated by CompressDebugSection). This
doesn't work because some code relies on symbols having fragments to
indicate that they're defined, I think.
2) Canonicalize the MCSymbolData in RecordRelocation to be "first
fragment + absolute offset" so it would be cheaper to just test and
update the fragment in CompressDebugSections. This doesn't work because
the offset computed in RecordRelocation isn't that of the symbol's
fragment, it's the passed in fragment (I haven't figured out what that
fragment is - perhaps it's the location where the relocation is to be
written). And if the fragment offset has to be computed only for this
use we might as well just do it when we need to, in
CompressDebugSection.
I also added an assert to help catch this a bit more clearly, even
though it is UB. The test case improvements would either assert fail
and/or valgrind vail without the fix, even if they wouldn't necessarily
fail the FileCheck output.
llvm-svn: 206653
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This port includes the rudimentary latencies that were provided for
the Cortex-A53 Machine Model in the AArch64 backend. It also changes
the SchedAlias for COPY in the Cyclone model to an explicit
WriteRes mapping to avoid conflicts in other subtargets.
Differential Revision: http://reviews.llvm.org/D3427
Patch by Dave Estes <cestes@codeaurora.org>!
llvm-svn: 206652
|
| |
|
|
| |
llvm-svn: 206651
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This pass was removed in r184459.
Also added note that the InstCombine pass does library call
simplification.
Patch slightly modified from one by Daniel Liew
<daniel.liew@imperial.ac.uk>!
llvm-svn: 206650
|
| |
|
|
| |
llvm-svn: 206649
|
| |
|
|
|
|
| |
Unlike Win32/x86, it has no "@12" suffix.
llvm-svn: 206648
|
| |
|
|
|
|
|
| |
LIBRARY directive in a module definition file specifies the output
DLL file name. It also takes an optional value for the base address.
llvm-svn: 206647
|
| |
|
|
|
|
|
| |
caught). Sad that we don't have warnings for these things, but bleh, no
idea how to fix that.
llvm-svn: 206646
|
| |
|
|
| |
llvm-svn: 206645
|
| |
|
|
|
|
|
| |
When transferring data from a CompilerInstance in an error path we need
to consider cases where the various fields are uninitialized.
llvm-svn: 206644
|
| |
|
|
|
|
|
|
| |
This changes the on-disk hash to get the type to use for offsets from
the Info type, so that clients can be more flexible with the size of
table they support.
llvm-svn: 206643
|
| |
|
|
|
|
|
|
| |
This changes the on-disk hash to get the size of a hash value from the
Info type, so that clients can be more flexible with the types of hash
they use.
llvm-svn: 206642
|
| |
|
|
|
|
|
|
|
|
|
| |
When address ranges for compile unit are specified in compile unit DIE
itself, there is no need to collect ranges from children subprogram DIEs.
This change speeds up llvm-symbolizer on Clang-produced binaries with
full debug info. For instance, symbolizing a first address in a 1Gb binary
is now 2x faster (1s vs. 2s).
llvm-svn: 206641
|
| |
|
|
|
|
|
|
| |
This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
llvm-svn: 206640
|
| |
|
|
| |
llvm-svn: 206639
|
| |
|
|
| |
llvm-svn: 206638
|
| |
|
|
| |
llvm-svn: 206637
|
| |
|
|
|
|
|
|
| |
/ignore:<number> is a linker option to disable warning specified by
the number. We ignore the option because it does not make sense for
LLD.
llvm-svn: 206636
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 206635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For a 256-bit BUILD_VECTOR consisting mostly of shuffles of 256-bit vectors,
both the BUILD_VECTOR and its operands may need to be legalized in multiple
steps. Consider:
(v8f32 (BUILD_VECTOR (extract_vector_elt (v8f32 %vreg0,) Constant<1>),
(extract_vector_elt %vreg0, Constant<2>),
(extract_vector_elt %vreg0, Constant<3>),
(extract_vector_elt %vreg0, Constant<4>),
(extract_vector_elt %vreg0, Constant<5>),
(extract_vector_elt %vreg0, Constant<6>),
(extract_vector_elt %vreg0, Constant<7>),
%vreg1))
a. We can't build a 256-bit vector efficiently so, we need to split it into
two 128-bit vecs and combine them with VINSERTX128.
b. Operands like (extract_vector_elt (v8f32 %vreg0), Constant<7>) needs to be
split into a VEXTRACTX128 and a further extract_vector_elt from the
resulting 128-bit vector.
c. The extract_vector_elt from b. is lowered into a shuffle to the first
element and a movss.
Depending on the order in which we legalize the BUILD_VECTOR and its
operands[1], buildFromShuffleMostly may be faced with:
(v4f32 (BUILD_VECTOR (extract_vector_elt
(vector_shuffle<1,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
(extract_vector_elt
(vector_shuffle<2,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
(extract_vector_elt
(vector_shuffle<3,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
%vreg1))
In order to figure out the underlying vector and their identity we need to see
through the shuffles.
[1] Note that the order in which operations and their operands are legalized is
only guaranteed in the first iteration of LegalizeDAG.
Fixes <rdar://problem/16296956>
llvm-svn: 206634
|
| |
|
|
|
|
|
| |
If the value for /manifestuac is "NO", LLD will create a manifest XM
file but won't emit <trustinfo> element.
llvm-svn: 206633
|
| |
|
|
| |
llvm-svn: 206632
|
| |
|
|
| |
llvm-svn: 206631
|
| |
|
|
| |
llvm-svn: 206630
|
| |
|
|
|
|
|
|
|
|
| |
This warning is disabled for the LLVM build,
but external users of the header can still
run into this.
Patch by Ke Bai
llvm-svn: 206629
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r206622 and the MSVC fixup in r206626.
Apparently the remotely failing tests are still failing, despite my
attempt to fix the nondeterminism in r206621.
llvm-svn: 206628
|
| |
|
|
| |
llvm-svn: 206627
|
| |
|
|
| |
llvm-svn: 206626
|
| |
|
|
| |
llvm-svn: 206625
|
| |
|
|
|
|
|
|
|
|
| |
Add a helper method to get address ranges specified in a DIE
(either by DW_AT_low_pc/DW_AT_high_pc, or by DW_AT_ranges). Use it
to untangle and simplify the code.
No functionality change.
llvm-svn: 206624
|
| |
|
|
|
|
| |
allocator, not construct one from scratch. Add a test to make sure
llvm-svn: 206623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206556, effectively reapplying commit r206548 and
its fixups in r206549 and r206550.
In an intervening commit I've added target triples to the tests that
were failing remotely [1] (but passing locally). I'm hoping the mystery
is solved? I'll revert this again if the tests are still failing
remotely.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
llvm-svn: 206622
|
| |
|
|
|
|
|
|
|
| |
These tests were failing on some buildbots after r206548 (reverted in
r206556), but passing locally.
They were missing target triples, so maybe that's the problem?
llvm-svn: 206621
|
| |
|
|
|
|
| |
on Linux per pr19478.
llvm-svn: 206620
|
| |
|
|
| |
llvm-svn: 206619
|
| |
|
|
|
|
| |
Follow-up patch coming to address test failures exposed by this change.
llvm-svn: 206618
|
| |
|
|
| |
llvm-svn: 206617
|
| |
|
|
| |
llvm-svn: 206616
|
| |
|
|
|
|
|
|
| |
Doesn't make sense to restrict this to BumpPtrAllocator. While there
replace an explicit loop with std::equal. Some standard libraries know
how to compile this down to a ::memcmp call if possible.
llvm-svn: 206615
|
| |
|
|
|
|
| |
Also, intentionally duplicate base class definitions per test, so it's easier to copy tests while debugging failures
llvm-svn: 206614
|
| |
|
|
|
|
|
| |
Mostly no testing this time, since they were just wrangling
target-specific intrinsics.
llvm-svn: 206613
|
| |
|
|
|
|
|
| |
This was a workaround for compilers that had issues with reference
collapsing.
llvm-svn: 206612
|
| |
|
|
|
|
| |
Part of PR19455.
llvm-svn: 206611
|
| |
|
|
|
|
| |
Part of PR19455.
llvm-svn: 206610
|
| |
|
|
| |
llvm-svn: 206609
|
| |
|
|
| |
llvm-svn: 206595
|
| |
|
|
|
|
|
| |
This is one of those DarwinPCS differences. It'd been caught in
arguments, but not return values.
llvm-svn: 206594
|