| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 89536
|
|
|
|
|
|
|
|
|
|
|
|
| |
When splitting a critical edge, the registers live through the edge are:
- Used in a PHI instruction, or
- Live out from the predecessor, and
- Live in to the successor.
This allows the coalescer to eliminate even more phi joins.
llvm-svn: 89530
|
|
|
|
|
|
|
| |
object size intrinsic and verify return type is correct. Collect various
code in one place.
llvm-svn: 89523
|
|
|
|
| |
llvm-svn: 89522
|
|
|
|
|
|
|
| |
and stores, handle the case where the element size is not
a valid target type correctly (PPC).
llvm-svn: 89521
|
|
|
|
|
|
| |
DIEs are created from MDNode, which are already uniqued. And DwarfDebug already uses ValueMaps to find and use existing DIE for a given MDNode.
llvm-svn: 89518
|
|
|
|
|
|
| |
comma-separated string or already parsed command line parameters as input, and some code re-factoring to use these new methods.
llvm-svn: 89516
|
|
|
|
|
|
| |
breaking.
llvm-svn: 89511
|
|
|
|
| |
llvm-svn: 89510
|
|
|
|
| |
llvm-svn: 89509
|
|
|
|
| |
llvm-svn: 89507
|
|
|
|
|
|
| |
and support for blockaddresses in x86-32 PIC mode.
llvm-svn: 89506
|
|
|
|
|
|
|
| |
Thanks to Daniel Dunbar for fixing clang intrinsics:
http://llvm.org/viewvc/llvm-project?view=rev&revision=89499
llvm-svn: 89500
|
|
|
|
|
|
| |
(PPC specific).
llvm-svn: 89496
|
|
|
|
|
|
| |
broke the Clang testsuite.
llvm-svn: 89495
|
|
|
|
|
|
|
| |
Also fixed the corresponding testcase, and the PALIGNR
intrinsic (tested for correctness with llvm-gcc).
llvm-svn: 89491
|
|
|
|
|
|
| |
Use ValueMap, instead of std::map.
llvm-svn: 89490
|
|
|
|
|
|
| |
Make things a little more efficient as suggested by Evan.
llvm-svn: 89489
|
|
|
|
| |
llvm-svn: 89487
|
|
|
|
|
|
|
|
|
|
|
|
| |
it may be used in contexts where preheader insertion may have failed due
to an indirectbr.
Make LoopSimplify's LoopSimplify::SeparateNestedLoop properly fail in
the case that it would require splitting an indirectbr edge.
These fix PR5502.
llvm-svn: 89484
|
|
|
|
|
|
| |
blockaddress users. This fixes PR5569.
llvm-svn: 89483
|
|
|
|
| |
llvm-svn: 89482
|
|
|
|
| |
llvm-svn: 89479
|
|
|
|
| |
llvm-svn: 89478
|
|
|
|
| |
llvm-svn: 89477
|
|
|
|
|
|
|
|
|
|
| |
constant pool ranges, as CPEIsInRange() makes conservative assumptions about
the potential alignment changes from branch adjustments. The verification,
on the other hand, runs after those branch adjustments are made, so the
effects on alignment are known and already taken into account. The sanity
check in verify should check the range directly instead.
llvm-svn: 89473
|
|
|
|
| |
llvm-svn: 89472
|
|
|
|
|
|
| |
additional, speculative scheduling pass as its cost did not translate into significant performance improvement. Minor tweaks.
llvm-svn: 89471
|
|
|
|
| |
llvm-svn: 89470
|
|
|
|
|
|
|
|
|
|
|
|
| |
same object to be a non-capture; Duncan pointed out a way that such
a comparison could be a capture.
Make the rule that considers a comparison against null more specific,
and only consider noalias return values compared against null. This
still supports test/Transforms/GVN/nonescaping-malloc.ll, and is not
susceptible to the problem Duncan pointed out with noalias arguments.
llvm-svn: 89468
|
|
|
|
|
|
|
|
| |
Makes '--comma-separated val1,val2' mean the same thing as
'--comma-separated=val1,val2' (that is, 'val1' and 'val2' are not lumped
together as 'val1,val2'). Also declutters the main loop a bit.
llvm-svn: 89463
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tests/Transforms/InstCombine/shufflemask-undef.ll. If
anyone cares, the use of 2*e here (and the equivalent
all over the place in instcombine) seems wrong, though
harmless: it should really be twice the length of the
input vector. I think shufflevector used to require
that the mask have the same length as the input, but I
don't think that's true any more. I don't care enough
about vectors to do anything about this...
llvm-svn: 89456
|
|
|
|
|
|
|
|
| |
which was an expensive checks failure due to a bug in the checking. This
patch in essence reverts the original fix for PR3393, and refixes it by a
tweak to the way expensive checking is done.
llvm-svn: 89454
|
|
|
|
|
|
| |
tail call has been encountered.
llvm-svn: 89444
|
|
|
|
| |
llvm-svn: 89443
|
|
|
|
| |
llvm-svn: 89440
|
|
|
|
|
|
| |
just before codegen.
llvm-svn: 89439
|
|
|
|
|
|
|
|
| |
because if the results from getUnderlyingObject match, the values must
be from the same underlying object, even if we don't know what that
object is.
llvm-svn: 89434
|
|
|
|
|
|
| |
Fix debug code that assumes getBasicBlock never returns NULL.
llvm-svn: 89428
|
|
|
|
| |
llvm-svn: 89426
|
|
|
|
|
|
| |
immediate forms of cmov instructions at all.
llvm-svn: 89423
|
|
|
|
| |
llvm-svn: 89422
|
|
|
|
|
|
|
|
|
| |
careful about crazy methods of capturing pointers using comparisons.
Comparisons of identified objects with null in the default address
space are not captures. And, comparisons of two pointers within the
same identified object are not captures.
llvm-svn: 89421
|
|
|
|
| |
llvm-svn: 89419
|
|
|
|
| |
llvm-svn: 89414
|
|
|
|
| |
llvm-svn: 89411
|
|
|
|
| |
llvm-svn: 89410
|
|
|
|
|
|
| |
Patch by Tobias Grosser!
llvm-svn: 89406
|
|
|
|
|
|
| |
breaking.
llvm-svn: 89404
|
|
|
|
|
|
|
|
|
|
|
| |
assembly can confuse things utterly, as it's assumed that instructions in
inline assembly are 4 bytes wide. For Thumb mode, that's often not true,
so the calculations for when alignment padding will be present get thrown off,
ultimately leading to out of range constant pool entry references. Making
more conservative assumptions that padding may be necessary when inline asm
is present avoids this situation.
llvm-svn: 89403
|