| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
This removes the libunwind build infrastructure as libunwind is gaining its own
CMakeLists.txt. The removal must occur first due to the multiple definitions of
the same target.
llvm-svn: 235794
|
| |
|
|
|
|
|
|
|
| |
This fixes a crash when we're emitting coverage and a macro appears
between two binary conditional operators, ie, "foo ?: MACRO ?: bar",
and fixes the interaction of macros and conditional operators in
general.
llvm-svn: 235793
|
| |
|
|
| |
llvm-svn: 235792
|
| |
|
|
| |
llvm-svn: 235791
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D9268
llvm-svn: 235790
|
| |
|
|
| |
llvm-svn: 235789
|
| |
|
|
|
|
|
| |
It misbehaves with absolute paths. (So does path::append().)
Goes with clang r235787.
llvm-svn: 235788
|
| |
|
|
|
|
|
|
|
| |
Before this patch, passing a non-existent absolute path to clang-cl would cause
stat'ing of impossible paths. For example, `clang-cl -c d:\adsfasdf.txt` would
cause a stat of
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIBd:\asdfadsf.cc
llvm-svn: 235787
|
| |
|
|
|
|
|
| |
Update `lib/Linker` to handle `Function` metadata attachments. The
attachments stick with the function body.
llvm-svn: 235786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add serialization support for function metadata attachments (added in
r235783). The syntax is:
define @foo() !attach !0 {
Metadata attachments are only allowed on functions with bodies. Since
they come before the `{`, they're not really part of the body; since
they require a body, they're not really part of the header. In
`LLParser` I gave them a separate function called from `ParseDefine()`,
`ParseOptionalFunctionMetadata()`.
In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by
instructions. Instruction metadata attachments are included in a
special "attachment" block at the end of a `Function`. The attachment
records are laid out like this:
InstID (KindID MetadataID)+
Note that these records always have an odd number of fields. The new
code takes advantage of this to recognize function attachments (which
don't need an instruction ID):
(KindID MetadataID)+
This means we can use the same attachment block already used for
instructions.
This is part of PR23340.
llvm-svn: 235785
|
| |
|
|
|
|
|
|
| |
Add a verifier check that only functions with bodies have metadata
attachments. This should help catch bugs in frontends and
transformation passes. Part of PR23340.
llvm-svn: 235784
|
| |
|
|
|
|
|
|
| |
Add IR support for `Metadata` attachments. Assembly and bitcode support
will follow shortly, but for now we just have unit tests. This is part
of PR23340.
llvm-svn: 235783
|
| |
|
|
|
|
|
|
| |
Remove unused `PFS` variable and take the `Instruction` by reference.
(Not really related to PR23340, but might as well clean this up while
I'm here.)
llvm-svn: 235782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
right scaling.
In the function canFoldInAddressingMode, VT is computed as the type of the
destination/source of a LOAD/STORE operations, instead of the memory type of the
operation.
On targets with a scaling factor on the offset of the LOAD/STORE operations, the
function may return false for actually valid cases. This may then prevent the
selection of profitable pre or post indexed load/store operations, and instead
select pre or post indexed load/store for unprofitable cases.
Patch by Francois de Ferriere <francois.de-ferriere@st.com>!
Differential Revision: http://reviews.llvm.org/D9146
llvm-svn: 235780
|
| |
|
|
| |
llvm-svn: 235779
|
| |
|
|
|
|
| |
Make the code reusable for `Function` metadata attachments (PR23340).
llvm-svn: 235778
|
| |
|
|
|
|
| |
PointerType::getElementType
llvm-svn: 235777
|
| |
|
|
|
|
| |
This just reduces the noise from another patch.
llvm-svn: 235776
|
| |
|
|
|
|
|
|
| |
Parameterize the separator for attachments, since `Function` metadata
attachments (PR23340) aren't going to use a `,` (comma). No real
functionality change.
llvm-svn: 235775
|
| |
|
|
|
|
|
|
| |
Collect metadata names once per `AssemblyWriter` instead of every time
we need to print some attachments. Just a drive-by; this caught my eye
while I was refactoring the code in r235772.
llvm-svn: 235774
|
| |
|
|
| |
llvm-svn: 235773
|
| |
|
|
|
|
|
| |
Refactor the code for printing `Instruction` metadata attachments so it
can be reused for `Function`.
llvm-svn: 235772
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
input type and use bit tests to check for holes
When using bit tests for hole checks, we call AddPredecessorToBlock to give the
phi node a value from the bit test block. This would break if we've
previously called removePredecessor on the default destination because the
switch is fully covered.
Test case by Mark Lacey.
llvm-svn: 235771
|
| |
|
|
|
|
|
|
| |
Make room for more than just `Function::isMaterializable()` in the
`GlobalObject` subclass data bitfield. Since we're treating it like a
bitfield, change `Function::Function()` to zero-out the whole thing.
llvm-svn: 235770
|
| |
|
|
|
|
|
|
|
|
|
| |
Extract the set logic for metadata attachments from `Instruction` so it
can be reused for `Function` (PR23340).
This data structure makes a `SmallVector<>` look (a little) like a map,
just doing the bare minimum to support the `Instruction` (and soon,
`Function`) metadata API.
llvm-svn: 235769
|
| |
|
|
|
|
|
|
|
| |
This introduces an intrinsic called llvm.eh.exceptioncode. It is lowered
by copying the EAX value live into whatever basic block it is called
from. Obviously, this only works if you insert it late during codegen,
because otherwise mid-level passes might reschedule it.
llvm-svn: 235768
|
| |
|
|
|
|
|
|
|
|
| |
Technically the operations are different -- the old logic moved items
from the back into the opened-up slots, instead of the usual
`remove_if()` logic of a slow and a fast iterator -- but unless a
profile tells us otherwise I prefer the simpler logic here. Regardless,
there shouldn't be an observable function change.
llvm-svn: 235767
|
| |
|
|
|
|
|
| |
These are related to libc++abi's personality routine and not core unwinding.
These have been restored in libc++abi, and are no longer needed here.
llvm-svn: 235766
|
| |
|
|
|
|
|
| |
These are apparently related to libc++'s unwind personality handler and not
unwind core. Move them back to the correct location.
llvm-svn: 235765
|
| |
|
|
|
|
|
| |
Remove some typedefs in preparation for factoring out attachment logic
from `Instruction`.
llvm-svn: 235764
|
| |
|
|
|
|
|
| |
Rename `MetadataStore` to the more explicit `InstructionMetadata`. This
will make room for `FunctionMetadata` (start of PR23340).
llvm-svn: 235763
|
| |
|
|
|
|
| |
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 235762
|
| |
|
|
| |
llvm-svn: 235761
|
| |
|
|
|
|
|
|
|
|
| |
The unwinder has been moved into its own project setup at
http://svn.llvm.org/projects/libunwind/trunk. This simply removes the now
duplicated content. This move was previously discussed on llvmdev at [1].
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081507.html
llvm-svn: 235759
|
| |
|
|
|
|
|
|
|
|
|
| |
This moves the majority of the unwind sources into the new project layout for
libunwind. This was previously discussed on llvmdev at [1]. This is a
purely movement related change, with the build infrastructure currently still
residing in the libc++abi repository.
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081507.html
llvm-svn: 235758
|
| |
|
|
|
|
| |
just a function type, not a pointer-to-function type
llvm-svn: 235756
|
| |
|
|
|
|
|
|
|
|
| |
the invoke instruction
Same as r235145 for the call instruction - the justification, tradeoffs,
etc are all the same. The conversion script worked the same without any
false negatives (after replacing 'call' with 'invoke').
llvm-svn: 235755
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D9241
llvm-svn: 235754
|
| |
|
|
|
|
|
| |
AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a
reference for this is crufty.
llvm-svn: 235752
|
| |
|
|
| |
llvm-svn: 235751
|
| |
|
|
| |
llvm-svn: 235750
|
| |
|
|
|
|
|
| |
AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a
reference for this is crufty.
llvm-svn: 235749
|
| |
|
|
| |
llvm-svn: 235747
|
| |
|
|
| |
llvm-svn: 235746
|
| |
|
|
| |
llvm-svn: 235744
|
| |
|
|
| |
llvm-svn: 235742
|
| |
|
|
| |
llvm-svn: 235741
|
| |
|
|
|
|
|
| |
If we're not being explicit, the test fails on windows.
Reported and tested by Aaron Ballman!
llvm-svn: 235739
|
| |
|
|
| |
llvm-svn: 235738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
executable.
Currently Symbols::LocateExecutableSymbolFile on MacOSX only looks for external
dsym debugging information, however if running on a stripped dwarf executable it
should also check for a .debug file as well.
Test Plan:
./dotest.py $DOTEST_OPTS -t -p TestSharedLibStrippedSymbols.py
This test now passes when running a remote Mac -> Linux test, and still passes
running locally on Mac or locally on Linux.
Differential Revision: http://reviews.llvm.org/D9174
llvm-svn: 235737
|