| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
We handle struct byval by inserting a pseudo op, which will be expanded to a
loop at ExpandISelPseudos.
A separate patch for clang will be submitted to enable struct byval.
rdar://9877866
llvm-svn: 157793
|
|
|
|
|
|
|
|
|
|
| |
to pass around a struct instead of a large set of individual values. This
cleans up the interface and allows more information to be added to the struct
for future targets without requiring changes to each and every target.
NV_CONTRIB
llvm-svn: 157479
|
|
|
|
| |
llvm-svn: 157152
|
|
|
|
|
|
|
|
|
|
|
| |
This will be used to determine whether it's profitable to turn a select into a
branch when the branch is likely to be predicted.
Currently enabled for everything but Atom on X86 and Cortex-A9 devices on ARM.
I'm not entirely happy with the name of this flag, suggestions welcome ;)
llvm-svn: 156233
|
|
|
|
| |
llvm-svn: 156189
|
|
|
|
|
|
|
|
| |
This moves the logic for selecting a TLS model to a single place,
instead of the previous three (ARM, Mips, and X86 which already
uses this function).
llvm-svn: 156162
|
|
|
|
|
|
|
|
| |
ARM BUILD_VECTORs created after type legalization cannot use i8 or i16
operands, since those types are not legal. Instead use i32 operands, which
will be implicitly truncated by the BUILD_VECTOR to match the element type.
llvm-svn: 155824
|
|
|
|
|
|
| |
since they are equivalent.
llvm-svn: 155188
|
|
|
|
| |
llvm-svn: 154439
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.
PR12419
rdar://9770785
rdar://11195178
llvm-svn: 154370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in-register, such that we can use a single vector store rather then a
series of scalar stores.
For func_4_8 the generated code
vldr d16, LCPI0_0
vmov d17, r0, r1
vadd.i16 d16, d17, d16
vmov.u16 r0, d16[3]
strb r0, [r2, #3]
vmov.u16 r0, d16[2]
strb r0, [r2, #2]
vmov.u16 r0, d16[1]
strb r0, [r2, #1]
vmov.u16 r0, d16[0]
strb r0, [r2]
bx lr
becomes
vldr d16, LCPI0_0
vmov d17, r0, r1
vadd.i16 d16, d17, d16
vuzp.8 d16, d17
vst1.32 {d16[0]}, [r2, :32]
bx lr
I'm not fond of how this combine pessimizes 2012-03-13-DAGCombineBug.ll,
but I couldn't think of a way to judiciously apply this combine.
This
ldrh r0, [r0, #4]
strh r0, [r1]
becomes
vldr d16, [r0]
vmov.u16 r0, d16[2]
vmov.32 d16[0], r0
vuzp.16 d16, d17
vst1.32 {d16[0]}, [r1, :32]
PR11158
rdar://10703339
llvm-svn: 154340
|
|
|
|
| |
llvm-svn: 154336
|
|
|
|
| |
llvm-svn: 154226
|
|
|
|
|
|
| |
which exists for this purpose.
llvm-svn: 154199
|
|
|
|
|
|
|
| |
ARM and Thumb2 mode can use cmn instructions to compare against negative
immediates. Thumb1 mode can't.
llvm-svn: 154183
|
|
|
|
|
|
|
|
| |
This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011
|
|
|
|
|
|
| |
tailcall opt. rdar://11140249
llvm-svn: 153717
|
|
|
|
|
|
| |
vmov.f32.
llvm-svn: 153696
|
|
|
|
| |
llvm-svn: 153500
|
|
|
|
| |
llvm-svn: 153422
|
|
|
|
| |
llvm-svn: 153421
|
|
|
|
|
|
|
| |
Patch by Weiming Zhao!
This fixes PR12212
llvm-svn: 153049
|
|
|
|
| |
llvm-svn: 152978
|
|
|
|
|
|
|
| |
register allocation by allowing all 32 D-registers to be used. Patch by Cameron
Zwarich.
llvm-svn: 152824
|
|
|
|
|
|
| |
uint16_t to reduce space.
llvm-svn: 152538
|
|
|
|
|
|
| |
size of static data.
llvm-svn: 151996
|
|
|
|
|
|
|
|
|
|
|
|
| |
floating point equality comparisons into integer ones with -ffast-math. The
issue is the optimization causes +0.0 != -0.0.
Now the optimization is only done when one side is known to be 0.0. The other
side's sign bit is masked off for the comparison.
rdar://10964603
llvm-svn: 151861
|
|
|
|
|
|
| |
direct call.
llvm-svn: 151645
|
|
|
|
|
|
| |
prediction. ...", it is breaking the Clang build during the Compiler-RT part.
llvm-svn: 151630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the processor keeps a return addresses stack (RAS) which stores the address
and the instruction execution state of the instruction after a function-call
type branch instruction.
Calling a "noreturn" function with normal call instructions (e.g. bl) can
corrupt RAS and causes 100% return misprediction so LLVM should use a
unconditional branch instead. i.e.
mov lr, pc
b _foo
The "mov lr, pc" is issued in order to get proper backtrace.
rdar://8979299
llvm-svn: 151623
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll let the buildbots determine the compile time improvements from this
change, but 464.h264ref has 5% faster codegen at -O2.
This patch does cause some assembly changes. Branch folding can make
different decisions about calls with dead return values.
CriticalAntiDepBreaker may choose different registers because its
liveness tracking is affected. MachineCopyPropagation may sometimes
leave a dead copy behind.
llvm-svn: 151331
|
|
|
|
|
|
|
| |
bits of the value carying the boolean condition, as their contents
are undefined. This fixes rdar://10887484.
llvm-svn: 151310
|
|
|
|
|
|
|
|
| |
of x are zero. This optimizes rev + lsr 16 to rev16.
rdar://10750814
llvm-svn: 151230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value is zero. Instead of a cmov + op, issue an conditional op instead. e.g.
cmp r9, r4
mov r4, #0
moveq r4, #1
orr lr, lr, r4
should be:
cmp r9, r4
orreq lr, lr, #1
That is, optimize (or x, (cmov 0, y, cond)) to (or.cond x, y). Similarly extend
this to xor as well as (and x, (cmov -1, y, cond)) => (and.cond x, y).
It's possible to extend this to ADD and SUB but I don't think they are common.
rdar://8659097
llvm-svn: 151224
|
|
|
|
|
|
| |
to static data that should not be modified.
llvm-svn: 151134
|
|
|
|
| |
llvm-svn: 151083
|
|
|
|
|
|
| |
Teach TargetSelectionDAG about lengthening loads for vector types and set v4i8 as legal. Allow FP_TO_UINT for v4i16 from v4i32.
llvm-svn: 150956
|
|
|
|
|
|
|
| |
marking them as "live-in" into a BB ruins some invariants that the back-end
tries to maintain.
llvm-svn: 150437
|
|
|
|
| |
llvm-svn: 150251
|
|
|
|
| |
llvm-svn: 149961
|
|
|
|
| |
llvm-svn: 149195
|
|
|
|
| |
llvm-svn: 149194
|
|
|
|
| |
llvm-svn: 148578
|
|
|
|
|
|
| |
unused variables).
llvm-svn: 148230
|
|
|
|
|
|
| |
CodeGen.
llvm-svn: 148218
|
|
|
|
|
|
| |
Darwin doesn't do static, and ELF targets only support static.
llvm-svn: 147740
|
|
|
|
|
|
| |
is discouraged now.
llvm-svn: 147738
|
|
|
|
|
|
|
|
|
|
|
| |
My change r146949 added register clobbers to the eh_sjlj_dispatchsetup pseudo
instruction, but on Thumb1 some of those registers cannot be used. This
caused massive failures on the testsuite when compiling for Thumb1. While
fixing that, I noticed that the eh_sjlj_setjmp instruction has a "nofp"
variant, and I realized that dispatchsetup needs the same thing, so I have
added that as well.
llvm-svn: 147204
|
|
|
|
|
|
| |
value that isn't a 32-bit value. (This is just to be safe; I don't think this actually causes any issues in practice.)
llvm-svn: 146700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
llvm-svn: 146466
|