The BasicBlock associated with a MachineBasicBlock does not necessarily
correspond to the code in the MBB.
Don't insert a new IR BasicBlock when splitting critical edges. We are not
supposed to modify the IR during codegen, and we should be able to do just
fine with a NULL BB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88707 91177308-0d34-0410-b5e6-96231b3b80d8
target-specific AsmPrinters. Not all comments need DebugInfo.
Re-enable the line numbers comment test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88697 91177308-0d34-0410-b5e6-96231b3b80d8
code-size win, and not when it's only likely to be code-size neutral,
such as when only a single instruction would be eliminated and a new
branch would be required.
This fixes rdar://7392894.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88692 91177308-0d34-0410-b5e6-96231b3b80d8
D0<def,dead> = ...
...
= S0<use, kill>
S0<def> = ...
...
D0<def> =
The first D0 def is correctly marked dead, however, livevariables should have
added an implicit def of S0 or we end up with a use without a def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88690 91177308-0d34-0410-b5e6-96231b3b80d8
Provide special isLoadFromStackSlotPostFE and isStoreToStackSlotPostFE
interfaces to explicitly request checking for post-frame ptr elimination
operands. This uses a heuristic so it isn't reliable for correctness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87047 91177308-0d34-0410-b5e6-96231b3b80d8
machine instruction loads or stores from/to a stack slot. Unlike
isLoadFromStackSlot and isStoreFromStackSlot, the instruction may be
something other than a pure load/store (e.g. it may be an arithmetic
operation with a memory operand). This helps AsmPrinter determine when
to print a spill/reload comment.
This is only a hint since we may not be able to figure this out in all
cases. As such, it should not be relied upon for correctness.
Implement for X86. Return false by default for other architectures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87026 91177308-0d34-0410-b5e6-96231b3b80d8
and don't assume that the call doesn't throw. It would be nice if there were a
way to determine which is the callee and which is a parameter. In practice, the
architecture we care about normally only have one operand for a call instruction
(x86 and arm).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87023 91177308-0d34-0410-b5e6-96231b3b80d8
slots. The AsmPrinter will use this information to determine whether to
print a spill/reload comment.
Remove default argument values. It's too easy to pass a wrong argument
value when multiple arguments have default values. Make everything
explicit to trap bugs early.
Update all targets to adhere to the new interfaces..
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87022 91177308-0d34-0410-b5e6-96231b3b80d8
making it visible to clients and adding LLVM-style cast capability.
This will be used by AsmPrinter to determine when to emit spill comments
for an instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87019 91177308-0d34-0410-b5e6-96231b3b80d8
to directly follow the jump table. Move the layout changes to prior to any
constant island handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86999 91177308-0d34-0410-b5e6-96231b3b80d8
running IPSCCP early, and we run functionattrs interlaced with the inliner,
we often (particularly for small or noop functions) completely propagate
all of the information about a call to its call site in IPSSCP (making a call
dead) and functionattrs is smart enough to realize that the function is
readonly (because it is interlaced with inliner).
To improve compile time and make the inliner threshold more accurate, realize
that we don't have to inline dead readonly function calls. Instead, just
delete the call. This happens all the time for C++ codes, here are some
counters from opt/llvm-ld counting the number of times calls were deleted vs
inlined on various apps:
Tramp3d opt:
5033 inline - Number of call sites deleted, not inlined
24596 inline - Number of functions inlined
llvm-ld:
667 inline - Number of functions deleted because all callers found
699 inline - Number of functions inlined
483.xalancbmk opt:
8096 inline - Number of call sites deleted, not inlined
62528 inline - Number of functions inlined
llvm-ld:
217 inline - Number of allocas merged together
2158 inline - Number of functions inlined
471.omnetpp:
331 inline - Number of call sites deleted, not inlined
8981 inline - Number of functions inlined
llvm-ld:
171 inline - Number of functions deleted because all callers found
629 inline - Number of functions inlined
Deleting a call is much faster than inlining it, and is insensitive to the
size of the callee. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86975 91177308-0d34-0410-b5e6-96231b3b80d8
cannot be folded into target cmp instruction.
- Avoid a phase ordering issue where early cmp optimization would prevent the
later count-to-zero optimization.
- Add missing checks which could cause LSR to reuse stride that does not have
users.
- Fix a bug in count-to-zero optimization code which failed to find the pre-inc
iv's phi node.
- Remove, tighten, loosen some incorrect checks disable valid transformations.
- Quite a bit of code clean up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86969 91177308-0d34-0410-b5e6-96231b3b80d8
making the new LVI stuff smart enough to subsume some special
cases in the old code. Disable them when LVI is around, the
testcase still passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86951 91177308-0d34-0410-b5e6-96231b3b80d8
This allows StringRef to skip controversial if(str) check in constructor.
Buildbots, wait for corresponding clang and llvm-gcc FE check-ins!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86914 91177308-0d34-0410-b5e6-96231b3b80d8
instead of typedefs for std::pair. This simplifies the type of
SameTails, which previously was std::vector<std::pair<std::vector<std::pair<unsigned, MachineBasicBlock *> >::iterator, MachineBasicBlock::iterator>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86885 91177308-0d34-0410-b5e6-96231b3b80d8
tail merging support to handle more cases.
- Recognize several cases where tail merging is beneficial even when
the tail size is smaller than the generic threshold.
- Make use of MachineInstrDesc::isBarrier to help detect
non-fallthrough blocks.
- Check for and avoid disrupting fall-through edges in more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86871 91177308-0d34-0410-b5e6-96231b3b80d8
- Edges are split before any phis are eliminated, so the code is SSA.
- Create a proper IR BasicBlock for the split edges.
- LiveVariables::addNewBlock now has same syntax as
MachineDominatorTree::addNewBlock. Algorithm calculates predecessor live-out
set rather than successor live-in set.
This feature still causes some miscompilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86867 91177308-0d34-0410-b5e6-96231b3b80d8
llvm.invariant.start to be used without necessarily being paired with a call
to llvm.invariant.end. If you run the entire optimization pipeline then such
calls are in fact deleted (adce does it), but that's actually a good thing since
we probably do want them to be zapped late in the game. There should really be
an integration test that checks that the llvm.invariant.start call lasts long
enough that all passes that do interesting things with it get to do their stuff
before it is deleted. But since no passes do anything interesting with it yet
this will have to wait for later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86840 91177308-0d34-0410-b5e6-96231b3b80d8
can only branch forward. To best take advantage of them, we'd like to adjust
the basic blocks around a bit when reasonable. This patch puts basics in place
to do that, with a super-simple algorithm for backwards jump table targets that
creates a new branch after the jump table which branches backwards. Real
heuristics for reordering blocks or other modifications rather than inserting
branches will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86791 91177308-0d34-0410-b5e6-96231b3b80d8
start using them in a trivial way when -enable-jump-threading-lvi
is passed. enable-jump-threading-lvi will be my playground for
awhile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86789 91177308-0d34-0410-b5e6-96231b3b80d8
constant whose component type is not a legal type for the target.
(If the target ConstantPool cannot handle this type either, it has
an opportunity to merge elements. In practice any target with
8-bit bytes must support i8 *as data*). 7320806 (partial).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86751 91177308-0d34-0410-b5e6-96231b3b80d8
generates a sequence similar to this:
__Z4funci:
LFB2:
mflr r0
LCFI0:
stmw r30,-8(r1)
LCFI1:
stw r0,8(r1)
LCFI2:
stwu r1,-80(r1)
LCFI3:
mr r30,r1
LCFI4:
where LCFI3 and LCFI4 are used by the FDE to indicate what the FP, LR, and other
things are. We generated something more like this:
Leh_func_begin1:
mflr r0
stw r31, 20(r1)
stw r0, 8(r1)
Llabel1:
stwu r1, -80(r1)
Llabel2:
mr r31, r1
Note that we are missing the "mr" instruction. This patch makes it more like the
GCC output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86729 91177308-0d34-0410-b5e6-96231b3b80d8
Critical edges leading to a PHI node are split when the PHI source variable is
live out from the predecessor block. This help the coalescer eliminate more
PHI joins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86725 91177308-0d34-0410-b5e6-96231b3b80d8
debug intrinsics, and an unconditional branch when possible. This
reuses the TryToSimplifyUncondBranchFromEmptyBlock function split
out of simplifycfg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86722 91177308-0d34-0410-b5e6-96231b3b80d8
- Force NDEBUG on in any Release build. This drops the compile time to ~100s
from ~600s, in Release mode.
- This may just be a temporary workaround, I don't know the true nature of the
gcc-4.2 compile time performance problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86695 91177308-0d34-0410-b5e6-96231b3b80d8
just one level deep. On the testcase we go from getting this:
F1: ; preds = %T2
%F = and i1 true, %cond ; <i1> [#uses=1]
br i1 %F, label %X, label %Y
to a fully threaded:
F1: ; preds = %T2
br label %Y
This changes gets us to the point where we're forming (too many) switch
instructions on doug's strswitch testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86646 91177308-0d34-0410-b5e6-96231b3b80d8
except that the result may not be a constant. Switch jump threading to
use it so that it gets things like (X & 0) -> 0, which occur when phi preds
are deleted and the remaining phi pred was a zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86637 91177308-0d34-0410-b5e6-96231b3b80d8
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86636 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify[IF]Cmp pieces. Add some predicates to CmpInst to
determine whether a predicate is fp or int.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86624 91177308-0d34-0410-b5e6-96231b3b80d8
takes decimated instructions and applies identities to them. This
is pretty minimal at this point, but I plan to pull some instcombine
logic out into these and similar routines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86613 91177308-0d34-0410-b5e6-96231b3b80d8
simplifies instruction users of PHIs when the phi is eliminated. This
will be moved to transforms/utils after some other refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86603 91177308-0d34-0410-b5e6-96231b3b80d8
was generated. This caused code like this:
## The asm code for the function
.section __TEXT,__const
.align 2
lJTI11_0:
LJTI11_0:
.long LBB11_16
.long LBB11_4
.long LBB11_5
.long LBB11_6
.long LBB11_7
.long LBB11_8
.long LBB11_9
.long LBB11_10
.long LBB11_11
.long LBB11_12
.long LBB11_13
.long LBB11_14
Leh_func_end11: ## <---now in the wrong section!
The `Leh_func_end11' would then end up in the wrong section, causing the
resulting EH frame information to be wrong:
__ZL11CheckRightsjPKcbRbRP6NSData.eh:
.set Lset500eh,Leh_frame_end11-Leh_frame_begin11
.long Lset500eh ; Length of Frame Information Entry
Leh_frame_begin11:
.long Leh_frame_begin11-Leh_frame_common
.long Leh_func_begin11-.
.set Lset501eh,Leh_func_end11-Leh_func_begin11
.long Lset501eh ; FDE address range
`Lset501eh' is now something huge instead of the real value.
The X86 back-end generates the jump table after the EH information is
emitted. Do the same here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86588 91177308-0d34-0410-b5e6-96231b3b80d8
the loop. This is needed because with indirectbr it may not be possible
for LoopSimplify to guarantee that all loop exit predecessors are
inside the loop. This fixes PR5437.
LCCSA no longer actually requires LoopSimplify form, but for now it
must still have the dependency because the PassManager doesn't know
how to schedule LoopSimplify otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86569 91177308-0d34-0410-b5e6-96231b3b80d8
here:
1) We need to avoid processing sigma nodes as phi nodes for constraint generation.
2) We need to generate constraints for comparisons against constants properly.
This includes our first working ABCD test!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86498 91177308-0d34-0410-b5e6-96231b3b80d8
graphs being produced. The cause was that we were incorrectly marking sigma instructions as
processed after handling the sigma-specific constraints for them, potentially neglecting to
process them as normal instructions as well.
Unfortunately, the testcase that inspired this still doesn't work because of a bug in the solver,
which is next on the list to debug.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86486 91177308-0d34-0410-b5e6-96231b3b80d8
when both the source and dest are illegal types, since it would cause
the phi to grow (for example, we shouldn't transform test14b's phi to
a phi on i320). This fixes an infinite loop on i686 bootstrap with
phi slicing turned on, so turn it back on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86483 91177308-0d34-0410-b5e6-96231b3b80d8
