lld might end up using a small part of this, but it will be in a much
refactored form. For now this unblocks avoiding the full section scan in the
ELFFile constructor.
This also has a (very small) error handling improvement.
llvm-svn: 244282
Summary:
This adds somewhat basic preparation functionality including:
- Formation of funclets via coloring basic blocks.
- Cloning of polychromatic blocks to ensure that funclets have unique
program counters.
- Demotion of values used between different funclets.
- Some amount of cleanup once we have removed predecessors from basic
blocks.
- Verification that we are left with a CFG that makes some amount of
sense.
N.B. Arguments and numbering still need to be done.
Reviewers: rnk, JosephTremoulet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11750
llvm-svn: 244272
A dSYM bundle is a file hierarchy that looks slike this:
<bundle name>.dSYM/
Contents/
Info.plist
Resources/
DWARF/
<DWARF file(s)>
This is the default output mode of dsymutil.
llvm-svn: 244270
dsymutil should by default generate dSYM bundles which are filesystem
hierarchies containing the debug info and an additional Info.plist.
Currently llvm-dsymutil emits raw binaries containing the debug info.
This is what we call the 'flat mode'. Add a -f/-flat option that is
supposed to enable that flat mode, but don't wire it for now, only
pass it to the tests that will need it to stay functional once we
do bundle generation by default.
This basically makes this commit NFC and removes the noise from the
actual commit that adds support for bundle generation.
llvm-svn: 244269
This adds documentation on how to use the new EH instructions added in
r243766.
Reviewers: majnemer, reames
Differential Revision: http://reviews.llvm.org/D11565
llvm-svn: 244267
After r244074, we now have a successors() method to iterate over
all the successors of a TerminatorInst. This commit changes a bunch
of eligible loops to use it.
llvm-svn: 244260
Summary: This allows us to consolidate several of the TableGen patterns.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11602
llvm-svn: 244253
libclang uses a CrashRecoveryContext, and building a module does too. If a
module gets built through libclang, nested CrashRecoveryContexts are used. They
work fine with threads as things are stored in ThreadLocal variables, but in
LLVM_ENABLE_THREADS=OFF builds the two recovery contexts would write to the
same globals.
To fix, keep active CrashRecoveryContextImpls in a list and have the global
point to the innermost one, and do something similar for
tlIsRecoveringFromCrash.
Necessary (but not sufficient) for PR11974 and PR20325
http://reviews.llvm.org/D11770
llvm-svn: 244251
points.
There is an infinite loop that can occur in Shrink Wrapping while searching
for the Save/Restore points.
Part of this search checks whether the save/restore points are located in
different loop nests and if so, uses the (post) dominator trees to find the
immediate (post) dominator blocks. However, if the current block does not have
any immediate (post) dominators then this search will result in an infinite
loop. This can occur in code containing an infinite loop.
The modification checks whether the immediate (post) dominator is different from
the current save/restore block. If it is not, then the search terminates and the
current location is not considered as a valid save/restore point for shrink wrapping.
Phabricator: http://reviews.llvm.org/D11607
llvm-svn: 244247
iisUnmovableInstruction() had a list of instructions hardcoded which are
considered unmovable. The list lacked (at least) an entry for the va_arg
and cmpxchg instructions.
Fix this by introducing a new Instruction::mayBeMemoryDependent()
instead of maintaining another instruction list.
Patch by Matthias Braun <matze@braunis.de>.
Differential Revision: http://reviews.llvm.org/D11577
rdar://problem/22118647
llvm-svn: 244244
It adds a new constructor, which takes a std::function predicate function that
is run at the beginning of shrink wrapping to determine whether the optimization
should run on the given machine function. The std::function can be overridden by
each target, allowing target-specific decisions to be made on each machine
function.
This is necessary for PowerPC, as the decision to run shrink wrapping is
partially based on the ABI. Futhermore, this operates nicely with the GCC iFunc
capability, which allows option overrides on a per-function basis.
Phabricator: http://reviews.llvm.org/D11421
llvm-svn: 244235
Summary: Divide the primitive size in bits by eight so the initial load's alignment is in bytes as expected. Tested with the included unit test.
Reviewers: rengolin, jfb
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11804
llvm-svn: 244229
This change improves EmitLoweredSelect() so that multiple contiguous CMOV pseudo
instructions with the same (or exactly opposite) conditions get lowered using a single
new basic-block. This eliminates unnecessary extra basic-blocks (and CFG merge points)
when contiguous CMOVs are being lowered.
Patch by: kevin.b.smith@intel.com
Differential Revision: http://reviews.llvm.org/D11428
llvm-svn: 244202
'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>::additionalSizeToAlloc' :
cannot access protected member declared in class
'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>'
I'm not sure how this compiles with gcc.
Aren't protecteded members accessible only with protected or public inheritance?
llvm-svn: 244199
This is the first mechanical step in preparation for making this and all
the other alias analysis passes available to the new pass manager. I'm
factoring out all the totally boring changes I can so I'm moving code
around here with no other changes. I've even minimized the formatting
churn.
I'll reformat and freshen comments on the interface now that its located
in the right place so that the substantive changes don't triger this.
llvm-svn: 244197
The COFFSymbolRef::isFunctionDefinition() function tests for several conditions
that are not related to whether a symbol is a function, but rather whether
the symbol meets the requirements for a function definition auxiliary record,
which excludes certain symbols such as internal functions and undefined
references. The test we need to determine the symbol type is much simpler:
we only need to compare the complex type against IMAGE_SYM_DTYPE_FUNCTION.
llvm-svn: 244195
