| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
linkage in -asan-initialization-order mode
llvm-svn: 168367
|
| |
|
|
|
|
| |
instrumented even in -asan-initialization-order mode. This time with a test
llvm-svn: 168366
|
| |
|
|
| |
llvm-svn: 168364
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The issue is that we may end up with newly OOB loads when speculating
a load into the predecessors of a PHI node, and this confuses the new
integer splitting logic in some cases, triggering an assertion failure.
In fact, the branch in question must be dead code as it loads from
a too-narrow alloca. Add code to handle this gracefully and leave the
requisite FIXMEs for both optimizing more aggressively and doing more to
aid sanitizing invalid code which triggers these patterns.
llvm-svn: 168361
|
| |
|
|
|
|
|
| |
+ Take account of clobbers
+ Give outputs priority over inputs since they happen later.
llvm-svn: 168360
|
| |
|
|
| |
llvm-svn: 168359
|
| |
|
|
| |
llvm-svn: 168357
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to properly handle the combinations of these with split integer loads
and stores. This essentially replaces Evan's r168227 by refactoring the
code in a different way, and trynig to mirror that refactoring in both
the load and store sides of the rewriting.
Generally speaking there was some really problematic duplicated code
here that led to poorly founded assumptions and then subtle bugs. Now
much of the code actually flows through and follows a more consistent
style and logical path. There is still a tiny bit of duplication on the
store side of things, but it is much less bad.
This also changes the logic to never re-use a load or store instruction
as that was simply too error prone in practice.
I've added a few tests (one a reduction of the one in Evan's original
patch, which happened to be the same as the report in PR14349). I'm
going to look at adding a few more tests for things I found and fixed in
passing (such as the volatile tests in the vectorizable predicate).
This patch has survived bootstrap, and modulo one bugfix survived
Duncan's test suite, but let me know if anything else explodes.
llvm-svn: 168346
|
| |
|
|
|
|
|
| |
It turned out that ARM wants different layout of type infos.
This is yet another patch in attempt to fix PR7187
llvm-svn: 168325
|
| |
|
|
|
|
| |
PR14376.
llvm-svn: 168320
|
| |
|
|
|
|
| |
Disable old JIT tests on PowerPC.
llvm-svn: 168316
|
| |
|
|
|
|
|
|
|
|
| |
operands of the expression being written was wrongly thought to be reusable as
an inner node of the expression resulting in it turning up as both an inner node
*and* a leaf, creating a cycle in the def-use graph. This would have caused the
verifier to blow up if things had gotten that far, however it managed to provoke
an infinite loop first.
llvm-svn: 168291
|
| |
|
|
| |
llvm-svn: 168283
|
| |
|
|
|
|
|
|
| |
emitted in @main().
XFAIL(s) can be removed.
llvm-svn: 168282
|
| |
|
|
| |
llvm-svn: 168281
|
| |
|
|
| |
llvm-svn: 168280
|
| |
|
|
| |
llvm-svn: 168249
|
| |
|
|
|
|
|
|
| |
On PPC the stack pointer is X1, but ADJCALLSTACK writes R1.
Fixes PR14315: Register regmask dependency problem with misched.
llvm-svn: 168248
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a partial solution to PR14351. It removes some of the special
significance of the first incoming phi value in the phi aliasing checking logic
in BasicAA. In the context of a loop, the old logic assumes that the first
incoming value is the interesting one (meaning that it is the one that comes
from outside the loop), but this is often not the case. With this change, we
now test first the incoming value that comes from a block other than the parent
of the phi being tested.
llvm-svn: 168245
|
| |
|
|
|
|
| |
Couperus.
llvm-svn: 168240
|
| |
|
|
|
|
|
| |
test cases require fixes to fast-isel before the verifier can be enabled.
Part of rdar://12594152
llvm-svn: 168233
|
| |
|
|
|
|
|
|
| |
example: *dst++ = *src++).
At the moment we still require to have an integer induction variable (for example: i++).
llvm-svn: 168231
|
| |
|
|
| |
llvm-svn: 168230
|
| |
|
|
|
|
| |
is narrower than the stored value. rdar://12713675
llvm-svn: 168227
|
| |
|
|
| |
llvm-svn: 168226
|
| |
|
|
| |
llvm-svn: 168221
|
| |
|
|
| |
llvm-svn: 168210
|
| |
|
|
|
|
|
|
|
| |
This patch replaces the hard coded GPR pair [R0, R1] of
Intrinsic:arm_ldrexd and [R2, R3] of Intrinsic:arm_strexd with
even/odd GPRPair reg class.
Similar to the lowering of atomic_64 operation.
llvm-svn: 168207
|
| |
|
|
|
|
| |
This fixes PR14359
llvm-svn: 168200
|
| |
|
|
|
|
| |
An alias to a function should use pc relative addressing.
llvm-svn: 168199
|
| |
|
|
|
|
| |
final assembly
llvm-svn: 168198
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before, the parser would assert on the following code:
@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0
because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.
llvm-svn: 168197
|
| |
|
|
| |
llvm-svn: 168195
|
| |
|
|
|
|
| |
but wasn't due to the same logic bug that caused PR14361.
llvm-svn: 168186
|
| |
|
|
|
|
|
|
|
| |
replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was. There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.
llvm-svn: 168181
|
| |
|
|
| |
llvm-svn: 168180
|
| |
|
|
|
|
| |
to pass on Atom.
llvm-svn: 168171
|
| |
|
|
| |
llvm-svn: 168166
|
| |
|
|
| |
llvm-svn: 168149
|
| |
|
|
|
|
|
|
|
|
|
| |
It turns out that the operands of a Constant are not always themselves
Constant. For example, one of the operands of BlockAddress is
BasicBlock, which is not a Constant.
This should fix the dragonegg-x86_64-linux-gcc-4.6-test build which
broke in r168037.
llvm-svn: 168147
|
| |
|
|
|
|
| |
vector types.
llvm-svn: 168141
|
| |
|
|
|
|
| |
allowed in branch delay slot.
llvm-svn: 168131
|
| |
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156007.html
llvm-svn: 168113
|
| |
|
|
|
|
|
|
| |
case to vector legalization so this actually works.
Patch by Pete Couperus. Fixes PR12540.
llvm-svn: 168107
|
| |
|
|
|
|
|
|
| |
This patch lowers the llvm.floor, llvm.ceil, llvm.trunc, and
llvm.nearbyint to Altivec instruction when using 4 single-precision
float vectors.
llvm-svn: 168086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.
This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.
llvm-svn: 168037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the utility for extracting a chain of operations from the IR, thought that it
might as well combine any constants it came across (rather than just returning
them along with everything else). On the other hand, the factorization code
would like to see the individual constants (this is quite reasonable: it is
much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6;
you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo
multiplications of constants as it may at first appear). This patch therefore
makes LinearizeExprTree stupider: it now leaves optimizing to the optimization
part of reassociate, and sticks to just analysing the IR.
llvm-svn: 168035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
PPC64 target. The five tests modified herein test code generation that is
sensitive to the code model selected. So I've added -code-model=small to
the RUN commands for each.
Since small code model is the default, this has no effect for now; but this
prepares us for eventually changing the default to medium code model for PPC64.
Test changes verified with small and medium code model as default on
powerpc64-unknown-linux-gnu. All tests continue to pass.
llvm-svn: 167999
|
| |
|
|
| |
llvm-svn: 167989
|
| |
|
|
|
|
| |
failure on i686 hosts.
llvm-svn: 167988
|