| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
converting from an MMX vector to an i64.
llvm-svn: 73024
|
| |
|
|
|
|
|
|
|
|
|
| |
on x86 to handle more cases. Fix a bug in said code that would cause it
to read past the end of an object. Rewrite the code in
SelectionDAGLegalize::ExpandBUILD_VECTOR to be a bit more general.
Remove PerformBuildVectorCombine, which is no longer necessary with
these changes. In addition to simplifying the code, with this change,
we can now catch a few more cases of consecutive loads.
llvm-svn: 73012
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 73009
|
| |
|
|
|
|
| |
types.
llvm-svn: 72993
|
| |
|
|
| |
llvm-svn: 72991
|
| |
|
|
|
|
|
|
| |
nodes for vectors with an i16 element type. Add an optimization for
building a vector which is all zeros/undef except for the bottom
element, where the bottom element is an i8 or i16.
llvm-svn: 72988
|
| |
|
|
| |
llvm-svn: 72987
|
| |
|
|
| |
llvm-svn: 72985
|
| |
|
|
|
|
|
| |
conversions for x86, like <2 x i32> -> <2 x float> and <4 x i16> ->
<4 x float>.
llvm-svn: 72983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
build vectors with i64 elements will only appear on 32b x86 before legalize.
Since vector widening occurs during legalize, and produces i64 build_vector
elements, the dag combiner is never run on these before legalize splits them
into 32b elements.
Teach the build_vector dag combine in x86 back end to recognize consecutive
loads producing the low part of the vector.
Convert the two uses of TLI's consecutive load recognizer to pass LoadSDNodes
since that was required implicitly.
Add a testcase for the transform.
Old:
subl $28, %esp
movl 32(%esp), %eax
movl 4(%eax), %ecx
movl %ecx, 4(%esp)
movl (%eax), %eax
movl %eax, (%esp)
movaps (%esp), %xmm0
pmovzxwd %xmm0, %xmm0
movl 36(%esp), %eax
movaps %xmm0, (%eax)
addl $28, %esp
ret
New:
movl 4(%esp), %eax
pmovzxwd (%eax), %xmm0
movl 8(%esp), %eax
movaps %xmm0, (%eax)
ret
llvm-svn: 72957
|
| |
|
|
|
|
| |
change no longer make sense after the coalescing changes we have made since then.
llvm-svn: 72955
|
| |
|
|
|
|
| |
a few lines later on.
llvm-svn: 72904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|
| |
|
|
|
|
|
| |
Update code generator to use this attribute and remove DisableRedZone target option.
Update llc to set this attribute when -disable-red-zone command line option is used.
llvm-svn: 72894
|
| |
|
|
|
|
| |
instead of the physical register it is allocated to. This resulted in virtual register(s) being added the live-in sets.
llvm-svn: 72890
|
| |
|
|
|
|
| |
unfortunate. But register allocator still has to add it to the live-in set of the use BB.
llvm-svn: 72888
|
| |
|
|
| |
llvm-svn: 72875
|
| |
|
|
|
|
| |
the code tried to use "push", which doesn't exist for XMM registers.)
llvm-svn: 72836
|
| |
|
|
| |
llvm-svn: 72830
|
| |
|
|
|
|
| |
MachineInstrBuilder::addReg() interface.
llvm-svn: 72826
|
| |
|
|
|
|
| |
DominatorTreeBase::Split.
llvm-svn: 72810
|
| |
|
|
|
|
|
|
| |
is assembly since Darwin assembler does not really support -static codeine.
I view this as a temporary workaround until the assembler / linker changes.
llvm-svn: 72806
|
| |
|
|
|
|
| |
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.
llvm-svn: 72758
|
| |
|
|
| |
llvm-svn: 72757
|
| |
|
|
| |
llvm-svn: 72756
|
| |
|
|
|
|
|
| |
relocation model on x86-64. Higher level logic should override
the relocation model to PIC on x86_64-apple-darwin.
llvm-svn: 72746
|
| |
|
|
|
|
|
| |
addresses, involving Base values which do not have Pointer type.
This fixes PR4297.
llvm-svn: 72739
|
| |
|
|
| |
llvm-svn: 72734
|
| |
|
|
|
|
| |
the top 8 bits.
llvm-svn: 72618
|
| |
|
|
| |
llvm-svn: 72560
|
| |
|
|
| |
llvm-svn: 72558
|
| |
|
|
| |
llvm-svn: 72557
|
| |
|
|
| |
llvm-svn: 72539
|
| |
|
|
| |
llvm-svn: 72517
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 72507
|
| |
|
|
| |
llvm-svn: 72485
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 72331
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 72328
|
| |
|
|
|
|
| |
running an extra DAGCombine pass which improves the code a bit.
llvm-svn: 72326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 72276
|
| |
|
|
|
|
|
|
|
|
|
|
| |
build an integer and cast that to a float. This fixes a crash
caused by trying to split an f32 into two f16's.
This changes the behavior in test/CodeGen/XCore/fneg.ll because that
testcase now triggers a DAGCombine which converts the fneg into an integer
operation. If someone is interested, it's probably possible to tweak
the test to generate an actual fneg.
llvm-svn: 72162
|
| |
|
|
| |
llvm-svn: 72161
|
| |
|
|
|
|
| |
relocation mode.
llvm-svn: 72160
|
| |
|
|
| |
llvm-svn: 72154
|
| |
|
|
|
|
| |
the stack. Patch by Sandeep Patel.
llvm-svn: 72106
|
| |
|
|
| |
llvm-svn: 72105
|
| |
|
|
| |
llvm-svn: 72002
|
| |
|
|
|
|
| |
better than nothing.
llvm-svn: 71976
|
| |
|
|
| |
llvm-svn: 71975
|
| |
|
|
|
|
|
|
| |
When a test fails with more than a pipeful of output on stdout AND stderr, one
of the DejaGnu programs blocks. The problem can be avoided by redirecting
stdout to a file.
llvm-svn: 71919
|