| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
then we don't want to set the destination in the indirect branch to the
destination. This is because the indirect branch needs its destinations to have
had their block addresses taken. This isn't so of the new critical edge that's
split during this process. If it turns out that the destination block has only
one predecessor, and that being a BB with an indirect branch, then it won't be
marked as 'used' and may be removed.
PR10072
llvm-svn: 132638
|
| |
|
|
|
|
|
| |
landing pad, forward llvm.eh.resume calls to it instead of turning them
invalidly into invokes.
llvm-svn: 132382
|
| |
|
|
|
|
| |
fixes self-host.
llvm-svn: 132275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transformed by the inliner into a branch to the enclosing landing pad
(when inlined through an invoke). If not so optimized, it is lowered
DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume
as appropriate). Its chief advantage is that it takes both the
exception value and the selector value as arguments, meaning that there
is zero effort in recovering these; however, the frontend is required
to pass these down, which is not actually particularly difficult.
Also document the behavior of landing pads a bit better, and make it
clearer that it's okay that personality functions don't always land at
landing pads. This is just a fact of life. Don't write optimizations that
rely on pushing things over an unwind edge.
llvm-svn: 132253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the selector for the landing pad must provide all available information
about the handlers, filters, and cleanups within that landing pad
- calls to _Unwind_Resume must be converted to branches to the enclosing
lpad so as to avoid re-entering the unwinder when the lpad claimed it
was going to handle the exception in some way
This is quite specific to libUnwind-based unwinding. In an effort to not
interfere too badly with other unwinders, and with existing hacks in frontends,
this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does
nothing with selectors if it cannot find a selector call for either lpad.
llvm-svn: 132200
|
| |
|
|
|
|
| |
question isn't actually in instcombine).
llvm-svn: 132170
|
| |
|
|
| |
llvm-svn: 131956
|
| |
|
|
|
|
| |
promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.
llvm-svn: 131953
|
| |
|
|
|
|
|
|
| |
to also clean up the condition of any conditional terminator it folds to be unconditional, if that turns the condition into dead code. This just means it calls RecursivelyDeleteTriviallyDeadInstructions() in strategic spots. It defaults to the old behavior.
I also changed -simplifycfg, -jump-threading and -codegenprepare to use this to produce slightly better code without any extra cleanup passes (AFAICT this was the only place in -simplifycfg where now-dead conditions of replaced terminators weren't being cleaned up). The only other user of this function is -sccp, but I didn't read that thoroughly enough to figure out whether it might be holding pointers to instructions that could be deleted by this.
llvm-svn: 131855
|
| |
|
|
|
|
| |
of the inlinee to the code representing the original function.
llvm-svn: 131838
|
| |
|
|
| |
llvm-svn: 131673
|
| |
|
|
| |
llvm-svn: 131620
|
| |
|
|
| |
llvm-svn: 131609
|
| |
|
|
| |
llvm-svn: 131607
|
| |
|
|
| |
llvm-svn: 131605
|
| |
|
|
| |
llvm-svn: 131598
|
| |
|
|
| |
llvm-svn: 131580
|
| |
|
|
| |
llvm-svn: 131571
|
| |
|
|
| |
llvm-svn: 131566
|
| |
|
|
| |
llvm-svn: 131561
|
| |
|
|
| |
llvm-svn: 131552
|
| |
|
|
| |
llvm-svn: 131551
|
| |
|
|
| |
llvm-svn: 131548
|
| |
|
|
| |
llvm-svn: 131545
|
| |
|
|
| |
llvm-svn: 131543
|
| |
|
|
| |
llvm-svn: 131541
|
| |
|
|
| |
llvm-svn: 131508
|
| |
|
|
| |
llvm-svn: 131480
|
| |
|
|
| |
llvm-svn: 131427
|
| |
|
|
|
|
| |
Radar 9422775.
llvm-svn: 131422
|
| |
|
|
| |
llvm-svn: 131345
|
| |
|
|
| |
llvm-svn: 130894
|
| |
|
|
|
|
| |
Instead, just use whatever location info first non-phi instruction has.
llvm-svn: 130729
|
| |
|
|
| |
llvm-svn: 130551
|
| |
|
|
| |
llvm-svn: 130528
|
| |
|
|
| |
llvm-svn: 130527
|
| |
|
|
|
|
| |
phi node folding
llvm-svn: 130526
|
| |
|
|
| |
llvm-svn: 130431
|
| |
|
|
| |
llvm-svn: 130068
|
| |
|
|
| |
llvm-svn: 129932
|
| |
|
|
| |
llvm-svn: 129759
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instruction around, reducing work.
Greatly simplify handling of debug instructions. There is no need to
build up a vector of them and then move them into the one predecessor
if we're processing a block. Instead just rescan the block and *copy*
them into the pred. If a block gets merged into multiple preds, this
will retain more debug info.
llvm-svn: 129502
|
| |
|
|
| |
llvm-svn: 129319
|
| |
|
|
| |
llvm-svn: 129271
|
| |
|
|
| |
llvm-svn: 129114
|
| |
|
|
|
|
| |
match.
llvm-svn: 129078
|
| |
|
|
| |
llvm-svn: 129041
|
| |
|
|
|
|
| |
values also.
llvm-svn: 129035
|
| |
|
|
|
|
|
| |
llvm-commits. (Not sure why it only breaks on Windows; maybe it has
something to do with the iterator representation...)
llvm-svn: 128802
|