| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
instead of the physical register it is allocated to. This resulted in virtual register(s) being added the live-in sets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72890 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
unfortunate. But register allocator still has to add it to the live-in set of the use BB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72888 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
there must also be an XFAIL line. Fix a couple
examples of this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72876 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
the code tried to use "push", which doesn't exist for XMM registers.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
MachineInstrBuilder::addReg() interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72826 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
DominatorTreeBase::Split.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
is assembly since Darwin assembler does not really support -static codeine.
I view this as a temporary workaround until the assembler / linker changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
be simplified to a loop-invariant value. This fixes PR4315.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
clear the register kill operand marker and its kill ops information. However, the cleared operand may be a def of a super-register. Clear the kill ops info for the super-register's sub-registers as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
relocation model on x86-64. Higher level logic should override
the relocation model to PIC on x86_64-apple-darwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
addresses, involving Base values which do not have Pointer type.
This fixes PR4297.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
can happen when PHI uses are recursively dependent on each other.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
RewriteStoreUserOfWholeAlloca deal with tail padding because
isSafeUseOfBitCastedAllocation expects them to. Otherwise, we crash
trying to erase the bitcast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
a single predecessor.
Patch by Jakub Staszak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
Benjamin Kramer!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
functions are being output with bodies and
available_externally linkage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72620 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
the top 8 bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72618 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
invoke results (see the testcases). Tighten up the checking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72560 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72558 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72557 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72517 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
empty SmallVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
e.g.
orl $65536, 8(%rax)
=>
orb $1, 10(%rax)
Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
rewrite the comparison if there is any implicit extension or truncation
on the induction variable. I'm planning for IVUsers to eventually take
over some of the work of this code, and for it to be generalized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72496 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
a smaller type, promoted its offset back up to the type of the new
comparison. This fixes PR4222.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72493 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72485 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
possible. For example, it now emits
%p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 2, i64 %tmp, i64 1
instead of the equivalent but less obvious
%p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 0, i64 %tmp, i64 19
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72452 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
beyond their associated static array type.
I believe that this fixes a legitimate bug, because BasicAliasAnalysis
already has code to check for this condition that works for non-constant
indices, however it was missing the case of constant indices. With this
change, it checks for both.
This fixes PR4267, and miscompiles of SPEC 188.ammp and 464.h264.href.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72451 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
division operation, don't attempt to use the operation's value as
the base of a getelementptr. This fixes PR4271.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72422 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
low-level alias() method, allowing it to reason more aggressively
about pointers into constant memory. PR4189
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72403 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
leave the original comparison in place if it has other uses, since the
other uses won't be dominated by the new comparison instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sending SCEVUnknowns to expandAddToGEP. This avoids the need for
expandAddToGEP to bend the rules and peek into SCEVUnknown
expressions.
Factor out the code for testing whether a SCEV can be factored by
a constant for use in a GEP index. This allows it to handle
SCEVAddRecExprs, by recursing.
As a result, SCEVExpander can now put more things in GEP indices,
so it emits fewer explicit mul instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
they are trivially dead.
Fix by clearing the rewriter cache before deleting the trivially dead
instructions.
Also make InsertedExpressions use an AssertingVH to catch these
bugs easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
running an extra DAGCombine pass which improves the code a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72326 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
instead of signed integer constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
code in preparation for code generation. The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads. Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about. However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds. Consider the following case:
In function @f:
...
invoke @g to label %normal unwind label %unwinds
...
unwinds:
%ex = call i8* @llvm.eh.exception()
...
In function @g:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
"rethrow exception"
Now inline @g into @f. Currently this is turned into:
In function @f:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
%ex = call i8* @llvm.eh.exception()
...
However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label. Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.
(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
unwind
This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering). But that means
you are using eh.exception again far from a landing pad.
(3) Bugpoint simplifications. When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.
Note that it is currently rare for this pass to actually do
anything. And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc! But it does fire
a few times in the testsuite. As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block. This other
block contains an eh.exception call. So probably by tweaking
LoopStrengthReduce a bit this can be avoided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assuming that the use of the value is in a block dominated by the
"normal" destination. LangRef.html and other documentation sources
don't explicitly guarantee this, but it seems to be assumed in
other places in LLVM at least.
This fixes an assertion failure on the included testcase, which
is derived from the Ada testsuite.
FixUsesBeforeDefs is a temporary measure which I'm looking to
replace with a more capable solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
use in expanding SCEVAddExprs with GEPs. The operands of a
SCEVMulExpr need to be multiplied together, not added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72250 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
indirect call into direct call, thus the verifier would reject something it
previously accepted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72249 91177308-0d34-0410-b5e6-96231b3b80d8
|