Commit Graph

100 Commits

Author SHA1 Message Date
Dmitri Gribenko
a6542923b8 Tests: rewrite 'opt ... %s' to 'opt ... < %s' so that opt does not emit a ModuleID
This is done to avoid odd test failures, like the one fixed in r171243.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171250 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-30 02:33:22 +00:00
Duncan Sands
b8e1111fbf Fix PR14060, an infinite loop in reassociate. The problem was that one of the
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168291 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-18 19:27:01 +00:00
Duncan Sands
7ecfcc1639 Fix a crash observed by Shuxin Yang. The issue here is that LinearizeExprTree,
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168035 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-15 09:58:38 +00:00
Shuxin Yang
4df2826166 revert r167740
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167787 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-13 00:08:49 +00:00
Shuxin Yang
0a46bf13a3 This change is to fix rdar://12571717 which is about assertion in Reassociate pass.
The assertion is trigged when the Reassociater tries to transform expression
     ... + 2 * n * 3 + 2 * m + ...
  into:
     ... + 2 * (n*3 + m).

In the process of the transformation, a helper routine folds the constant 2*3 into 6,
confusing optimizer which is trying the to eliminate the common factor 2, and cannot
find 2 any more. 

Review is pending. But I'd like commit first in order to help those who are waiting 
for this fix. 


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167740 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-12 19:34:11 +00:00
Duncan Sands
20b2d21509 Stop reassociate from looking through expressions of arbitrary complexity. This
is a temporary measure until my fix for PR13021 is ready.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160778 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-26 09:26:40 +00:00
Chandler Carruth
4177e6fff5 Convert all tests using TCL-style quoting to use shell-style quoting.
This was done through the aid of a terrible Perl creation. I will not
paste any of the horrors here. Suffice to say, it require multiple
staged rounds of replacements, state carried between, and a few
nested-construct-parsing hacks that I'm not proud of. It happens, by
luck, to be able to deal with all the TCL-quoting patterns in evidence
in the LLVM test suite.

If anyone is maintaining large out-of-tree test trees, feel free to poke
me and I'll send you the steps I used to convert things, as well as
answer any painful questions etc. IRC works best for this type of thing
I find.

Once converted, switch the LLVM lit config to use ShTests the same as
Clang. In addition to being able to delete large amounts of Python code
from 'lit', this will also simplify the entire test suite and some of
lit's architecture.

Finally, the test suite runs 33% faster on Linux now. ;]
For my 16-hardware-thread (2x 4-core xeon e5520): 36s -> 24s

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159525 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-02 12:47:22 +00:00
Duncan Sands
96d2eff5c6 Fix a reassociate crash on sozefx when compiling with dragonegg+gcc-4.7 due to
the optimizers producing a multiply expression with more multiplications than
the original (!).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159426 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-29 13:25:06 +00:00
Duncan Sands
2d5f8ca3d1 Some reassociate optimizations create new instructions, which they insert just
before the expression root.  Any existing operators that are changed to use one
of them needs to be moved between it and the expression root, and recursively
for the operators using that one.  When I rewrote RewriteExprTree I accidentally
inverted the logic, resulting in the compacting going down from operators to
operands rather than up from operands to the operators using them, oops.  Fix
this, resolving PR12963.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159265 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-27 14:19:00 +00:00
Nick Lewycky
917f99354f Remove a dangling reference to a deleted instruction. Fixes PR13185!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159096 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-24 01:44:08 +00:00
Duncan Sands
cd117f736c Fix issues (infinite loop and/or crash) with self-referential instructions, for
example degenerate phi nodes and binops that use themselves in unreachable code.
Thanks to Charles Davis for the testcase that uncovered this can of worms.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158508 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-15 08:37:50 +00:00
Duncan Sands
d34491f675 It is possible for several constants which aren't individually absorbing to
combine to the absorbing element.  Thanks to nbjoerg on IRC for pointing this 
out.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158399 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-13 12:15:56 +00:00
Duncan Sands
ac071eac30 Use std::map rather than SmallMap because SmallMap assumes that the value has
POD type, causing memory corruption when mapping to APInts with bitwidth > 64.
Merge another crash testcase into crash.ll while there.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158369 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-12 20:16:51 +00:00
Duncan Sands
c038a78335 Now that Reassociate's LinearizeExprTree can look through arbitrary expression
topologies, it is quite possible for a leaf node to have huge multiplicity, for
example: x0 = x*x, x1 = x0*x0, x2 = x1*x1, ... rapidly gives a value which is x
raised to a vast power (the multiplicity, or weight, of x).  This patch fixes
the computation of weights by correctly computing them no matter how big they
are, rather than just overflowing and getting a wrong value.  It turns out that
the weight for a value never needs more bits to represent than the value itself,
so it is enough to represent weights as APInts of the same bitwidth and do the
right overflow-avoiding dance steps when computing weights.  As a side-effect it
reduces the number of multiplies needed in some cases of large powers.  While
there, in view of external uses (eg by the vectorizer) I made LinearizeExprTree
static, pushing the rank computation out into users.  This is progress towards
fixing PR13021.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158358 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-12 14:33:56 +00:00
Duncan Sands
69938a85bd Revert commit 158073 while waiting for a fix. The issue is that reassociate
can move instructions within the instruction list.  If the instruction just
happens to be the one the basic block iterator is pointing to, and it is
moved to a different basic block, then we get into an infinite loop due to
the iterator running off the end of the basic block (for some reason this
doesn't fire any assertions).  Original commit message:

Grab-bag of reassociate tweaks.  Unify handling of dead instructions and
instructions to reoptimize.  Exploit this to more systematically eliminate
dead instructions (this isn't very useful in practice but is convenient for
analysing some testcase I am working on).  No need for WeakVH any more: use
an AssertingVH instead.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158199 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-08 13:37:30 +00:00
Duncan Sands
b933586592 Grab-bag of reassociate tweaks. Unify handling of dead instructions and
instructions to reoptimize.  Exploit this to more systematically eliminate
dead instructions (this isn't very useful in practice but is convenient for
analysing some testcase I am working on).  No need for WeakVH any more: use
an AssertingVH instead.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158073 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-06 14:53:10 +00:00
Duncan Sands
eacc31acf5 Since commit 157467, if reassociate isn't actually going to change an expression
then it doesn't alter the instructions composing it, however it would continue
to move the instructions to just before the expression root.  Ensure it doesn't
move them either, so now it really does nothing if there is nothing to do.  That
commit also ensured that nsw etc flags weren't cleared if the expression was not
being changed.  Tweak this a bit so that it doesn't clear flags on the initial
part of a computation either if that part didn't change but later bits did.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157518 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-26 16:42:52 +00:00
Duncan Sands
0fd120b970 Make the reassociation pass more powerful so that it can handle expressions
with arbitrary topologies (previously it would give up when hitting a diamond
in the use graph for example).  The testcase from PR12764 is now reduced from
a pile of additions to the optimal 1617*%x0+208.  In doing this I changed the
previous strategy of dropping all uses for expression leaves to one of dropping
all but one use.  This works out more neatly (but required a bunch of tweaks)
and is also safer: some recently fixed bugs during recursive linearization were
because the linearization code thinks it completely owns a node if it has no uses
outside the expression it is linearizing.  But if the node was also in another
expression that had been linearized (and thus all uses of the node from that
expression dropped) then the conclusion that it is completely owned by the
expression currently being linearized is wrong.  Keeping one use from within each
linearized expression avoids this kind of mistake.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157467 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-25 12:03:02 +00:00
Duncan Sands
a337010989 Calling ReassociateExpression recursively is extremely dangerous since it will
replace the operands of expressions with only one use with undef and generate
a new expression for the original without using RAUW to update the original.
Thus any copies of the original expression held in a vector may end up
referring to some bogus value - and using a ValueHandle won't help since there
is no RAUW.  There is already a mechanism for getting the effect of recursion
non-recursively: adding the value to be recursed on to RedoInsts.  But it wasn't
being used systematically.  Have various places where recursion had snuck in at
some point use the RedoInsts mechanism instead.  Fixes PR12169.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156379 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-08 12:16:05 +00:00
Owen Anderson
423f19f2da Teach reassociate to commute FMul's and FAdd's in order to canonicalize the order of their operands across instructions. This allows for greater CSE opportunities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156323 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-07 20:47:23 +00:00
Bill Wendling
55e7098bbc The value held in the vector may be RAUW'ed by some of the canonicalization
methods. Use a weak value handle to keep up with this.
PR12245


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155984 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-02 09:59:45 +00:00
Chandler Carruth
464bda3a16 Teach the reassociate pass to fold chains of multiplies with repeated
elements to minimize the number of multiplies required to compute the
final result. This uses a heuristic to attempt to form near-optimal
binary exponentiation-style multiply chains. While there are some cases
it misses, it seems to at least a decent job on a very diverse range of
inputs.

Initial benchmarks show no interesting regressions, and an 8%
improvement on SPASS. Let me know if any other interesting results (in
either direction) crop up!

Credit to Richard Smith for the core algorithm, and helping code the
patch itself.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155616 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-26 05:30:30 +00:00
Chandler Carruth
a3e3481c57 Tidy up this test more:
1) Make the checked assertions a bit more precise. We really want the
   canonical forms coming out of reassociate to be exactly what is
   expected.
2) Remove other passes, and switch the test to actually directly check
   that reassociate makes the important transforms and
   canonicalizations.
3) Fold in a related test case now that we're using FileCheck. Make the
   same tidying changes to it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155311 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-22 10:11:26 +00:00
Chandler Carruth
71f8bc37f2 FileCheck-ize a test, and tidy it up a touch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155310 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-22 10:11:23 +00:00
Eli Bendersky
0f0c411079 Replace all instances of dg.exp file with lit.local.cfg, since all tests are run with LIT now and now Dejagnu. dg.exp is no longer needed.
Patch reviewed by Daniel Dunbar. It will be followed by additional cleanup patches.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150664 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16 06:28:33 +00:00
Benjamin Kramer
7a3824b923 Remove empty test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136675 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-02 02:47:45 +00:00
Owen Anderson
9b7fdc7e8a Revert r136503 and r136480 in an effort to fix non-determinism in the llvm-gcc buildbots on i386. Devang is looking into the root cause.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136674 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-02 02:23:42 +00:00
Devang Patel
1619560521 Clean up debug info after reassociation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136480 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-29 19:00:35 +00:00
Chris Lattner
1afcace3a3 Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-09 17:41:24 +00:00
Dan Gohman
dac5dbadeb Fix reassociate to use a worklist instead of recursing when new
reassociation opportunities are exposed. This fixes a bug where
the nested reassociation expects to be the IR to be consistent,
but it isn't, because the outer reassociation has disconnected
some of the operands.  rdar://9167457


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129324 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-12 00:11:56 +00:00
Dan Gohman
fa0e6facc7 Fix reassociate to postpone certain instruction deletions until
after it has finished all of its reassociations, because its
habit of unlinking operands and holding them in a datastructure
while working means that it's not easy to determine when an
instruction is really dead until after all its regular work is
done. rdar://9096268.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127424 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-10 19:51:54 +00:00
Chris Lattner
de1d8a544c fix PR9215, preventing -reassociate from clearing nsw/nuw when
it swaps the LHS/RHS of a single binop.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125700 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-17 01:29:24 +00:00
Dan Gohman
46985a1440 Fix reassociate to clear optional flags, such as nsw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124712 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-02 02:02:34 +00:00
Duncan Sands
37f87c7aa9 Fix PR9039, a use-after-free in reassociate. The issue was that the
operand being factorized (and erased) could occur several times in Ops,
resulting in freed memory being used when the next occurrence in Ops was
analyzed.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124287 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-26 10:08:38 +00:00
Chris Lattner
893075f46e fix a nice subtle reassociate bug which would only occur
in a very specific use pattern embodied in the carefully
reduced testcase.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97794 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-05 07:18:54 +00:00
Bob Wilson
8d535859e5 Add a test for my change to disable reassociation for i1 types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95465 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-06 01:16:25 +00:00
Chris Lattner
f08872048f filecheckize
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93775 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-18 21:58:32 +00:00
Chris Lattner
c2d1b6949c only factor from expressions whose uses are empty and whose
base is the right expression type.  This fixes PR5981.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93045 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-09 06:01:36 +00:00
Chris Lattner
5f94af0f72 fix an infinite loop in reassociate building emacs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92679 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-05 04:55:35 +00:00
Chris Lattner
9506c930aa When factoring multiply expressions across adds, factor both
positive and negative forms of constants together.  This 
allows us to compile:

int foo(int x, int y) {
    return (x-y) + (x-y) + (x-y);
}

into:

_foo:                                                       ## @foo
	subl	%esi, %edi
	leal	(%rdi,%rdi,2), %eax
	ret

instead of (where the 3 and -3 were not factored):

_foo:
        imull   $-3, 8(%esp), %ecx
        imull   $3, 4(%esp), %eax
        addl    %ecx, %eax
        ret

this started out as:
    movl    12(%ebp), %ecx
    imull   $3, 8(%ebp), %eax
    subl    %ecx, %eax
    subl    %ecx, %eax
    subl    %ecx, %eax
    ret

This comes from PR5359.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92381 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-01 01:13:15 +00:00
Chris Lattner
75954e0bbd test case we alredy get right.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92380 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-01 00:50:00 +00:00
Chris Lattner
3523993451 reuse negates where possible instead of always creating them from scratch.
This allows us to optimize test12 into:

define i32 @test12(i32 %X) {
  %factor = mul i32 %X, -3                        ; <i32> [#uses=1]
  %Z = add i32 %factor, 6                         ; <i32> [#uses=1]
  ret i32 %Z
}

instead of:

define i32 @test12(i32 %X) {
  %Y = sub i32 6, %X                              ; <i32> [#uses=1]
  %C = sub i32 %Y, %X                             ; <i32> [#uses=1]
  %Z = sub i32 %C, %X                             ; <i32> [#uses=1]
  ret i32 %Z
}



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92373 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-31 20:34:32 +00:00
Chris Lattner
69e98e2c0f teach reassociate to factor x+x+x -> x*3. While I'm at it,
fix RemoveDeadBinaryOp to actually do something.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92368 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-31 19:24:52 +00:00
Chris Lattner
13a754ce92 simple fix for an incorrect factoring which causes a
miscompilation, PR5458.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92354 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-31 08:33:49 +00:00
Chris Lattner
7f4ae5c84c merge some more tests in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92353 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-31 08:32:22 +00:00
Chris Lattner
e1f5460f78 filecheckize
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92352 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-31 08:29:56 +00:00
Dan Gohman
b7c0b246da Convert more tests to avoid llvm-as.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81545 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-11 18:36:27 +00:00
Dan Gohman
f2f6ce65b7 Change tests from "opt %s" to "opt < %s" so that opt doesn't see the
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81537 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-11 18:01:28 +00:00
Dan Gohman
9c7a988e3b Use "opt < %s" instead of "opt %s" so that opt doesn't print the test
filename in the output, which interferes with the tests' grep lines.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81263 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-08 22:57:49 +00:00
Dan Gohman
3e054fe9ef Use opt -S instead of piping bitcode output through llvm-dis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81257 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-08 22:34:10 +00:00