Commit Graph

4320 Commits

Author SHA1 Message Date
Meador Inge
73d8a5864f instcombine: Migrate strcat and strncat optimizations
This patch migrates the strcat and strncat optimizations from the
simplify-libcalls pass into the instcombine library call simplifier.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165874 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-13 16:45:32 +00:00
Chandler Carruth
07525a6be6 Teach SROA to cope with wrapper aggregates. These show up a lot in ABI
type coercion code, especially when targetting ARM. Things like [1
x i32] instead of i32 are very common there.

The goal of this logic is to ensure that when we are picking an alloca
type, we look through such wrapper aggregates and across any zero-length
aggregate elements to find the simplest type possible to form a type
partition.

This logic should (generally speaking) rarely fire. It only ends up
kicking in when an alloca is accessed using two different types (for
instance, i32 and float), and the underlying alloca type has wrapper
aggregates around it. I noticed a significant amount of this occurring
looking at stepanov_abstraction generated code for arm, and suspect it
happens elsewhere as well.

Note that this doesn't yet address truly heinous IR productions such as
PR14059 is concerning. Those result in mismatched *sizes* of types in
addition to mismatched access and alloca types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165870 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-13 10:49:33 +00:00
Nick Lewycky
5e01f80bf8 Don't crash when !tbaa.struct contents is invalid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165693 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 02:05:23 +00:00
Duncan Sands
ea46827d6c Add the testcase from pr13254 (the old scalarreply pass handles this wrong;
the new sroa pass handles it right).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165644 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-10 18:41:19 +00:00
Michael Ilseman
440ae6800e New EarlyCSE tests for CSE-ing across commutativity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165510 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-09 16:58:13 +00:00
Alexey Samsonov
e97a3a4b4f Fix PR14016.
DeadArgumentElimination pass can replace one LLVM function with another,
invalidating a pointer stored in debug info metadata entry for this function.
To fix this, we collect debug info descriptors for functions before
running a DeadArgumentElimination pass and "patch" pointers in metadata nodes
if we replace a function.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165490 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-09 08:13:15 +00:00
Chandler Carruth
2fdb25b5a9 Fix PR14034, an infloop / heap corruption / crash bug in the new SROA.
Thanks to Benjamin for the raw test case. This one took about 50 times
longer to reduce than to fix. =/

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165476 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-09 01:58:35 +00:00
Micah Villmow
791cfc211a Move TargetData to DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165403 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-08 16:39:34 +00:00
Chandler Carruth
fca3f4021a Teach the new SROA a new trick. Now we zap any memcpy or memmoves which
are in fact identity operations. We detect these and kill their
partitions so that even splitting is unaffected by them. This is
particularly important because Clang relies on emitting identity memcpy
operations for struct copies, and these fold away to constants very
often after inlining.

Fixes the last big performance FIXME I have on my plate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165285 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-05 01:29:09 +00:00
Benjamin Kramer
1e21db6e83 SimplifyCFG: Enhance the "remove CFG edge that leads to null pointer dereference" optimization to also handle instructions with multiple uses.
We conservatively only check the first use to avoid walking long use chains.
This catches the common case of having both a load and a store to a pointer
supplied by a PHI node.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165232 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 16:11:49 +00:00
Duncan Sands
7508f946bc In my recent change to avoid use of underaligned memory I didn't notice that
cpyDest can be mutated in some cases, which would then cause a crash later if
indeed the memory was underaligned.  This brought down several buildbots, so
I guess the underaligned case is much more common than I thought!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165228 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 13:53:21 +00:00
Duncan Sands
ffcf6dffee The alignment of an sret parameter is known: it must be at least the
alignment of the return type.  Teach the optimizers this.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165226 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 13:36:31 +00:00
Chandler Carruth
b2d98c2917 Fix PR13969, a mini-phase-ordering issue with the new SROA pass.
Currently, we re-visit allocas when something changes about the way they
might be *split* to allow better scalarization to take place. However,
we weren't handling the case when the *promotion* is what would change
the behavior of SROA. When an address derived from an alloca is stored
into another alloca, we consider the first to have escaped. If the
second is ever promoted to an SSA value, we will suddenly be able to run
the SROA pass on the first alloca.

This patch adds explicit support for this form if iteration. When we
detect a store of a pointer derived from an alloca, we flag the
underlying alloca for reprocessing after promotion. The logic works hard
to only do this when there is definitely going to be promotion and it
might remove impediments to the analysis of the alloca.

Thanks to Nick for the great test case and Benjamin for some sanity
check review.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165223 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 12:33:50 +00:00
Duncan Sands
f58747517c The memcpy optimizer was happily doing call slot forwarding when the new memory
was less aligned than the old.  In the testcase this results in an overaligned
memset: the memset alignment was correct for the original memory but is too much
for the new memory.  Fix this by either increasing the alignment of the new
memory or bailing out if that isn't possible.  Should fix the gcc-4.7 self-host
buildbot failure.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165220 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 10:54:40 +00:00
Chandler Carruth
aa3cb334af Teach the integer-promotion rewrite strategy to be endianness aware.
Sorry for this being broken so long. =/

As part of this, switch all of the existing tests to be Little Endian,
which is the behavior I was asserting in them anyways! Add in a new
big-endian test that checks the interesting behavior there.

Another part of this is to tighten the rules abotu when we perform the
full-integer promotion. This logic now rejects cases where there fully
promoted integer is a non-multiple-of-8 bitwidth or cases where the
loads or stores touch bits which are in the allocated space of the
alloca but are not loaded or stored when accessing the integer. Sadly,
these aren't really observable today as the rest of the pass will
already ensure the invariants hold. However, the latter situation is
likely to become a potential concern in the future.

Thanks to Benjamin and Duncan for early review of this patch. I'm still
looking into whether there are further endianness issues, please let me
know if anyone sees BE failures persisting past this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165219 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-04 10:39:28 +00:00
Jakub Staszak
395c1502a7 Fix PR13967.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165187 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-03 23:59:47 +00:00
Chandler Carruth
322e9ba2cb Fix an issue where we failed to adjust the alignment constraint on
a memcpy to reflect that '0' has a different meaning when applied to
a load or store. Now we correctly use underaligned loads and stores for
the test case added.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165101 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-03 08:26:28 +00:00
Chandler Carruth
f710fb14ee Try to use a better set of abstractions for computing the alignment
necessary during rewriting. As part of this, fix a real think-o here
where we might have left off an alignment specification when the address
is in fact underaligned. I haven't come up with any way to trigger this,
as there is always some other factor that reduces the alignment, but it
certainly might have been an observable bug in some way I can't think
of. This also slightly changes the strategy for placing explicit
alignments on loads and stores to only do so when the alignment does not
match that required by the ABI. This causes a few redundant alignments
to go away from test cases.

I've also added a couple of tests that really push on the alignment that
we end up with on loads and stores. More to come here as I try to fix an
underlying bug I have conjectured and produced test cases for, although
it's not clear if this bug is the one currently hitting dragonegg's
gcc47 bootstrap.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-03 08:14:02 +00:00
Chandler Carruth
5c5b3cf5b8 Teach the new SROA to handle cases where an alloca that has already been
scheduled for processing on the worklist eventually gets deleted while
we are processing another alloca, fixing the original test case in
PR13990.

To facilitate this, add a remove_if helper to the SetVector abstraction.
It's not easy to use the standard abstractions for this because of the
specifics of SetVectors types and implementation.

Finally, a nice small test case is included. Thanks to Benjamin for the
fantastic reduced test case here! All I had to do was delete some empty
basic blocks!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165065 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-02 22:46:45 +00:00
Benjamin Kramer
fba80d9e97 Fix broken tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165019 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-02 15:49:34 +00:00
Chandler Carruth
cfb65293c3 Fix more misspellings found by Duncan during review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164940 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-01 12:30:45 +00:00
Chandler Carruth
673850aa2d Fix several issues with alignment. We weren't always accounting for type
alignment requirements of the new alloca. As one consequence which was
reported as a bug by Duncan, we overaligned memcpy calls to ranges of
allocas after they were rewritten to types with lower alignment
requirements. Other consquences are possible, but I don't have any test
cases for them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164937 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-01 12:16:54 +00:00
Benjamin Kramer
64f27e78c4 SimplifyCFG: Don't crash when forming a switch bitmap with an undef default value.
Fixes PR13985.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164934 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-01 11:31:48 +00:00
Chandler Carruth
77c1270033 Refactor the PartitionUse structure to actually use the Use* instead of
a pair of instructions, one for the used pointer and the second for the
user. This simplifies the representation and also makes it more dense.

This was noticed because of the miscompile in PR13926. In that case, we
were running up against a fundamental "bad idea" in the speculation of
PHI and select instructions: the speculation and rewriting are
interleaved, which requires phi speculation to also perform load
rewriting! This is bad, and causes us to miss opportunities to do (for
example) vector rewriting only exposed after PHI speculation, etc etc.
It also, in the old system, required us to insert *new* load uses into
the current partition's use list, which would then be ignored during
rewriting because we had already extracted an end iterator for the use
list. The appending behavior (and much of the other oddities) stem from
the strange de-duplication strategy in the PartitionUse builder.
Amusingly, all this went without notice for so long because it could
only be triggered by having *different* GEPs into the same partition of
the same alloca, where both different GEPs were operands of a single
PHI, and where the GEP which was not encountered first also had multiple
uses within that same PHI node... Hence the insane steps required to
reproduce.

So, step one in fixing this fundamental bad idea is to make the
PartitionUse actually contain a Use*, and to make the builder do proper
deduplication instead of funky de-duplication. This is enough to remove
the appending behavior, and fix the miscompile in PR13926, but there is
more work to be done here. Subsequent commits will lift the speculation
into its own visitor. It'll be a useful step toward potentially
extracting all of the speculation logic into a generic utility
transform.

The existing PHI test case for repeated operands has been made more
extreme to catch even these issues. This test case, run through the old
pass, will exactly reproduce the miscompile from PR13926. ;] We were so
close here!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164925 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-01 01:49:22 +00:00
Chandler Carruth
b67c9a5b02 Fix a somewhat surprising miscompile where code relying on an ABI
alignment could lose it due to the alloca type moving down to a much
smaller alignment guarantee.

Now SROA will actively compute a proper alignment, factoring the target
data, any explicit alignment, and the offset within the struct. This
will in some cases lower the alignment requirements, but when we lower
them below those of the type, we drop the alignment entirely to give
freedom to the code generator to align it however is convenient.

Thanks to Duncan for the lovely test case that pinned this down. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164891 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-29 10:41:21 +00:00
Evan Cheng
aa7e47416a Add test case for r164850.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164867 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-29 00:12:08 +00:00
Benjamin Kramer
8be16fe703 CorrelatedPropagation: BasicBlock::removePredecessor can simplify PHI nodes. If the it's the condition of a SwitchInst, reload it.
Fixes PR13972.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164818 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-28 10:42:50 +00:00
Benjamin Kramer
ab16423c91 GlobalOpt: non-constexpr bitcasts or GEPs can occur even if the global value is only stored once.
Fixes PR13968.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164815 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-28 10:01:27 +00:00
Nick Lewycky
7e0e166d17 Surprisingly, we missed a trivial case here. Fix that!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164814 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-28 09:33:53 +00:00
Meador Inge
ce71822d38 instcombine: Add more test cases for __strncpy_chk simplification
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164800 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 21:21:31 +00:00
Meador Inge
a968582978 instcombine: Add more test cases for __strcpy_chk simplification
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164799 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 21:21:28 +00:00
Meador Inge
c8613c9089 instcombine: Add more test cases for __memmove_chk simplification
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164798 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 21:21:25 +00:00
Meador Inge
012ffd251b instcombine: Add more test cases for __memcpy_chk simplification
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164797 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 21:21:21 +00:00
Meador Inge
910c564d3b instcombine: Add more test cases for __memset_chk simplification
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164796 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 21:21:18 +00:00
Benjamin Kramer
465251a7ce Fix a integer overflow in SimplifyCFG's look up table formation logic.
If the width is very large it gets truncated from uint64_t to uint32_t when
passed to TD->fitsInLegalInteger. The truncated value can fit in a register.
This manifested in massive memory usage or crashes (PR13946).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164784 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 18:29:58 +00:00
Sylvestre Ledru
94c22716d6 Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164768 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 10:14:43 +00:00
Sylvestre Ledru
7e2c793a2b Fix a typo 'iff' => 'if'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164767 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 09:59:43 +00:00
Nick Lewycky
466e0f38d3 Prefer shuffles to selects. Backends love shuffles!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164763 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-27 08:33:56 +00:00
Hans Wennborg
50b7d70707 Address Duncan's comments on r164684:
- Put statistics in alphabetical order
- Don't use getZextValue when building TableInt, just use APInts
- Introduce Create{Z,S}ExtOrTrunc in IRBuilder.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164696 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 14:01:53 +00:00
Chandler Carruth
238fd1591e When rewriting the pointer operand to a load or store which has
alignment guarantees attached, re-compute the alignment so that we
consider offsets which impact alignment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164690 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 10:45:28 +00:00
Chandler Carruth
81b001a220 Teach all of the loads, stores, memsets and memcpys created by the
rewriter in SROA to carry a proper alignment. This involves
interrogating various sources of alignment, etc. This is a more complete
and principled fix to PR13920 as well as related bugs pointed out by Eli
in review and by inspection in the area.

Also by inspection fix the integer and vector promotion paths to create
aligned loads and stores. I still need to work up test cases for
these... Sorry for the delay, they were found purely by inspection.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164689 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 10:27:46 +00:00
Benjamin Kramer
e7381cc99c Fix tests that didn't test anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164686 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 09:51:39 +00:00
Hans Wennborg
d72271cd84 SimplifyCFG: Make the switch-to-lookup table transformation store the
tables in bitmaps when they fit in a target-legal register.

This saves some space, and it also allows for building tables that would
otherwise be deemed too sparse.

One interesting case that this hits is example 7 from
http://blog.regehr.org/archives/320. We currently generate good code
for this when lowering the switch to the selection DAG: we build a
bitmask to decide whether to jump to one block or the other. My patch
will result in the same bitmask, but it removes the need for the jump,
as the return value can just be retrieved from the mask.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164684 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 09:44:49 +00:00
Chandler Carruth
b3dca3f50e Revert the business end of r164636 and try again. I'll come in again. ;]
This should really, really fix PR13916. For real this time. The
underlying bug is... a bit more subtle than I had imagined.

The setup is a code pattern that leads to an @llvm.memcpy call with two
equal pointers to an alloca in the source and dest. Now, not any pattern
will do. The alloca needs to be formed just so, and both pointers should
be wrapped in different bitcasts etc. When this precise pattern hits,
a funny sequence of events transpires. First, we correctly detect the
potential for overlap, and correctly optimize the memcpy. The first
time. However, we do simplify the set of users of the alloca, and that
causes us to run the alloca back through the SROA pass in case there are
knock-on simplifications. At this point, a curious thing has happened.
If we happen to have an i8 alloca, we have direct i8 pointer values. So
we don't bother creating a cast, we rewrite the arguments to the memcpy
to dircetly refer to the alloca.

Now, in an unrelated area of the pass, we have clever logic which
ensures that when visiting each User of a particular pointer derived
from an alloca, we only visit that User once, and directly inspect all
of its operands which refer to that particular pointer value. However,
the mechanism used to detect memcpy's with the potential to overlap
relied upon getting visited once per *Use*, not once per *User*. This is
always true *unless* the same exact value is both source and dest. It
turns out that almost nothing actually produces that pattern though.

We can hand craft test cases that more directly test this behavior of
course, and those are included. Also, note that there is a significant
missed optimization here -- we prove in many cases that there is
a non-volatile memcpy call with identical source and dest addresses. We
shouldn't prevent splitting the alloca in that case, and in fact we
should just remove such memcpy calls eagerly. I'll address that in
a subsequent commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164669 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-26 07:41:40 +00:00
Nick Lewycky
051a318e67 Don't drop the alignment on a memcpy intrinsic when producing a store. This is
only a missed optimization opportunity if the store is over-aligned, but a
miscompile if the store's new type has a higher natural alignment than the
memcpy did. Fixes PR13920!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164641 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-25 22:46:21 +00:00
Nick Lewycky
c3f10e43fc Don't try to promote the same alloca twice. Fixes PR13916!
Chandler, it's not obvious that it's okay that this alloca gets into the list
twice to begin with. Please review and see whether this is the fix you really
want, but I wanted to get a fix checked in quickly.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164634 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-25 21:15:50 +00:00
Nick Lewycky
fe4a778f6e Make this test check the transforms it's actually doing. Also add a test that it
doesn't transform the trivially unsafe case.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164617 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-25 18:17:38 +00:00
Chandler Carruth
c303463dcc Fix a case where SROA did not correctly detect dead PHI or selects due
to chains or cycles between PHIs and/or selects. Also add a couple of
really nice test cases reduced from Kostya's reports in PR13905 and
PR13906. Both are fixed by this patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164596 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-25 10:03:40 +00:00
Nick Lewycky
24ab21c691 Don't forget that strcpy and friends return a pointer to the destination, so
it's not a dead store if that pointer is used. Whoops!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164583 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-25 01:55:59 +00:00
Nick Lewycky
3dbefbd9bb Teach DSE that strcpy, strncpy, strcat and strncat are all stores which may be
dead.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164561 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-24 22:09:10 +00:00