671 Commits

Author SHA1 Message Date
Andrew Trick
c3765e6af0 SCEV: Add MarkPendingLoopPredicates to avoid recursive isImpliedCond.
getUDivExpr attempts to simplify by checking for overflow.
isLoopEntryGuardedByCond then evaluates the loop predicate which
may lead to the same getUDivExpr causing endless recursion.

Fixes PR12868: clang 3.2 segmentation fault.

llvm-svn: 157092
2012-05-19 00:48:25 +00:00
Nuno Lopes
40c48e0924 reuse the result of some expensive computations in getSignExtendExpr() and getZeroExtendExpr()
this gives a speedup of > 80 in a debug build in the test case of PR12825 (php_sha512_crypt_r)

llvm-svn: 156849
2012-05-15 20:20:14 +00:00
Nuno Lopes
9cdc8c5146 minor simplification to code: Ty is already a SCEV type; don't need to run getEffectiveSCEVType() twice
llvm-svn: 156823
2012-05-15 15:44:38 +00:00
Dan Gohman
bfbda3087c Rewrite ScalarEvolution::hasOperand to use an explicit worklist instead
of recursion, to avoid excessive stack usage on deep expressions.

llvm-svn: 156554
2012-05-10 17:21:30 +00:00
Benjamin Kramer
550faddc94 Revert "SCEV: When expanding a GEP the final addition to the base pointer has NUW but not NSW."
This isn't right either, reverting for now.

llvm-svn: 154910
2012-04-17 06:33:57 +00:00
Benjamin Kramer
a690750db9 SCEV: When expanding a GEP the final addition to the base pointer has NUW but not NSW.
Found by inspection.

llvm-svn: 154262
2012-04-07 17:19:26 +00:00
Rafael Espindola
88a1aeb123 Always compute all the bits in ComputeMaskedBits.
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
2012-04-04 12:51:34 +00:00
Andrew Trick
88a52fd943 SCEV fix: Handle loop invariant loads.
Fixes PR11882: NULL dereference in ComputeLoadConstantCompareExitLimit.

llvm-svn: 153480
2012-03-26 22:33:59 +00:00
Chris Lattner
265280c247 switch SCEV to use the new ConstantFoldLoadThroughGEPIndices function
instead of its own hard coded thing, allowing it to handle 
ConstantDataSequential and fixing some obscure bugs (e.g. it would
previously crash on a CAZ of vector type).

llvm-svn: 148788
2012-01-24 05:49:24 +00:00
David Blaikie
06ecc99a56 More dead code removal (using -Wunreachable-code)
llvm-svn: 148578
2012-01-20 21:51:11 +00:00
Benjamin Kramer
1d768583f5 Remove obviously invalid early exit that prevented analyzing ConstantAggregateZeros.
Found by the clang static analyzer.

llvm-svn: 148540
2012-01-20 14:42:25 +00:00
Andrew Trick
1454836d05 Clarified the SCEV getSmallConstantTripCount interface with in-your-face comments.
This interface is misleading and dangerous, but it is actually what we need for unrolling.

llvm-svn: 147926
2012-01-11 06:52:55 +00:00
Andrew Trick
60f6beef61 Expose isNonConstantNegative to users of ScalarEvolution.
llvm-svn: 147700
2012-01-07 00:27:31 +00:00
Chad Rosier
fdca220a9e Fix a few more places where TargetData/TargetLibraryInfo is not being passed.
Add FIXMEs to places that are non-trivial to fix.

llvm-svn: 145661
2011-12-02 01:26:24 +00:00
Chad Rosier
0b4bd4832a Last bit of TargetLibraryInfo propagation. Also fixed a case for TargetData
where it appeared beneficial to pass.
More of rdar://10500969

llvm-svn: 145630
2011-12-01 21:29:16 +00:00
Chad Rosier
49a66381f7 Propagate TargetLibraryInfo throughout ConstantFolding.cpp and
InstructionSimplify.cpp.  Other fixups as needed.
Part of rdar://10500969

llvm-svn: 145559
2011-12-01 03:08:23 +00:00
Andrew Trick
63f81b112e SCEV fix. In general, Add/Mul expressions should not inherit NSW/NUW.
This reverts r139450, fixes r139453, and adds much needed comments and a
unit test.

llvm-svn: 145367
2011-11-29 02:16:38 +00:00
Andrew Trick
975fe6c09b Make SCEV print <nsw><nuw> for Add/MulExpr.
llvm-svn: 145364
2011-11-29 02:06:35 +00:00
Benjamin Kramer
fbd156b1d5 SCEV: Actually set overflow flags on add expressions.
setFlags doesn't modify its arguments.

llvm-svn: 145007
2011-11-20 10:24:36 +00:00
Andrew Trick
fe618116fc Fix SCEV overly optimistic back edge taken count for multi-exit loops.
Fixes PR11375: Different results for 'clang++ huh.cpp'...

llvm-svn: 144746
2011-11-16 00:52:40 +00:00
Nick Lewycky
772024a00d Don't try to loop on iterators that are potentially invalidated inside the loop. Fixes PR11361!
llvm-svn: 144454
2011-11-12 03:09:12 +00:00
Nick Lewycky
c08fa4916a Don't forget to check FlagNW when determining whether an AddRecExpr will wrap
or not. Patch by Brendon Cahoon!

llvm-svn: 144173
2011-11-09 07:11:37 +00:00
Duncan Sands
be9c2e6e13 Restore commits 142790 and 142843 - they weren't breaking the build
bots.  Original commit messages:
- Reapply r142781 with fix. Original message:

  Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
  loop header when computing the trip count.

  With this, we now constant evaluate:
    struct ListNode { const struct ListNode *next; int i; };
    static const struct ListNode node1 = {0, 1};
    static const struct ListNode node2 = {&node1, 2};
    static const struct ListNode node3 = {&node2, 3};
    int test() {
      int sum = 0;
      for (const struct ListNode *n = &node3; n != 0; n = n->next)
        sum += n->i;
      return sum;
    }

- Now that we look at all the header PHIs, we need to consider all the header PHIs
  when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
  torture testsuite!

llvm-svn: 142919
2011-10-25 12:28:52 +00:00
Duncan Sands
da835efa2a Speculatively revert commits 142790 and 142843 to see if it fixes
the dragonegg and llvm-gcc self-host buildbots.  Original commit
messages:
- Reapply r142781 with fix. Original message:

  Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
  loop header when computing the trip count.

  With this, we now constant evaluate:
    struct ListNode { const struct ListNode *next; int i; };
    static const struct ListNode node1 = {0, 1};
    static const struct ListNode node2 = {&node1, 2};
    static const struct ListNode node3 = {&node2, 3};
    int test() {
      int sum = 0;
      for (const struct ListNode *n = &node3; n != 0; n = n->next)
        sum += n->i;
      return sum;
    }

- Now that we look at all the header PHIs, we need to consider all the header PHIs
when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
torture testsuite!

llvm-svn: 142916
2011-10-25 09:26:43 +00:00
Nick Lewycky
289c30130a Now that we look at all the header PHIs, we need to consider all the header PHIs
when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
torture testsuite!

llvm-svn: 142843
2011-10-24 21:02:38 +00:00
Nick Lewycky
64d4e26aec Reapply r142781 with fix. Original message:
Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
  loop header when computing the trip count.

  With this, we now constant evaluate:
    struct ListNode { const struct ListNode *next; int i; };
    static const struct ListNode node1 = {0, 1};
    static const struct ListNode node2 = {&node1, 2};
    static const struct ListNode node3 = {&node2, 3};
    int test() {
      int sum = 0;
      for (const struct ListNode *n = &node3; n != 0; n = n->next)
        sum += n->i;
      return sum;
    }

llvm-svn: 142790
2011-10-24 06:57:05 +00:00
Nick Lewycky
341bf1548e PHI nodes not in the loop header aren't part of the loop iteration initial
state. Furthermore, they might not have two operands. This fixes the underlying
issue behind the crashes introduced in r142781.

llvm-svn: 142788
2011-10-24 05:51:01 +00:00
Nick Lewycky
d72de74587 Speculatively revert r142781. Bots are showing
Assertion `i_nocapture < OperandTraits<PHINode>::operands(this) && "getOperand() out of range!"' failed.
coming out of indvars.

llvm-svn: 142786
2011-10-24 04:00:25 +00:00
Nick Lewycky
5ab7948d71 Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
loop header when computing the trip count.

With this, we now constant evaluate:
  struct ListNode { const struct ListNode *next; int i; };
  static const struct ListNode node1 = {0, 1};
  static const struct ListNode node2 = {&node1, 2};
  static const struct ListNode node3 = {&node2, 3};
  int test() {
    int sum = 0;
    for (const struct ListNode *n = &node3; n != 0; n = n->next)
      sum += n->i;
    return sum;
  }

llvm-svn: 142781
2011-10-23 23:43:14 +00:00
Nick Lewycky
ce8bfeadff Make SCEV's brute force analysis stronger in two ways. Firstly, we should be
able to constant fold load instructions where the argument is a constant.
Second, we should be able to watch multiple PHI nodes through the loop; this
patch only supports PHIs in loop headers, more can be done here.

With this patch, we now constant evaluate:
  static const int arr[] = {1, 2, 3, 4, 5};
  int test() {
    int sum = 0;
    for (int i = 0; i < 5; ++i) sum += arr[i];
    return sum;
  }

llvm-svn: 142731
2011-10-22 19:58:20 +00:00
Nick Lewycky
610fc64d78 An instruction's operands aren't necessarily instructions or constants. They
could be arguments, for example.

No testcase because this is a bug-fix broken out of a larger optimization patch.

llvm-svn: 141951
2011-10-14 09:38:46 +00:00
Andrew Trick
671f73b951 Fixes PR11070 - assert in SCEV getConstantEvolvingPHIOperands.
llvm-svn: 141219
2011-10-05 22:06:53 +00:00
Andrew Trick
94a7b27585 Typo. Thanks Bob.
llvm-svn: 141188
2011-10-05 16:52:28 +00:00
Chandler Carruth
9fc5856d54 Fix a broken assert found by -Wparentheses.
llvm-svn: 141168
2011-10-05 07:02:23 +00:00
Andrew Trick
79a14ca34e Fix disabled SCEV analysis caused r141161 and add unit test.
I noticed during self-review that my previous checkin disabled some
analysis. Even with the reenabled analysis the test case runs in about
5ms. Without the fix, it will take several minutes at least.

llvm-svn: 141164
2011-10-05 05:58:49 +00:00
Andrew Trick
5789485111 Avoid exponential recursion in SCEV getConstantEvolvingPHI and EvaluateExpression.
Note to compiler writers: never recurse on multiple instruction
operands without memoization.
Fixes rdar://10187945. Was taking 45s, now taking 5ms.

llvm-svn: 141161
2011-10-05 03:25:31 +00:00
Nick Lewycky
6833d72fc0 The product of two chrec's can always be represented as a chrec.
llvm-svn: 141066
2011-10-04 06:51:26 +00:00
Nick Lewycky
4898eef762 Reapply r140979 with fix! We never did get a testcase, but careful review of the
logic by David Meyer revealed this bug.

llvm-svn: 140992
2011-10-03 07:10:45 +00:00
Nick Lewycky
79fec8116f Revert r140979 due to reports of bootstrap failure.
llvm-svn: 140980
2011-10-03 05:14:59 +00:00
Nick Lewycky
a760a29395 Add one more case we compute a max trip count.
llvm-svn: 140979
2011-10-03 01:03:57 +00:00
Andrew Trick
50915b5136 indvars: generalize SCEV getPreStartForSignExtend.
Handle general Add expressions to avoid leaving around redundant
32-bit IVs.

llvm-svn: 140701
2011-09-28 17:02:54 +00:00
Andrew Trick
8af62b87e4 Set NSW/NUW flags on SCEVAddExpr when the operation is flagged as
such.

I'm doing this now for completeness because I can't think of/remember
any reason that it was left out. I'm not sure it will help anything,
but if we don't do it we need to explain why in comments.

llvm-svn: 139450
2011-09-10 01:09:50 +00:00
Nick Lewycky
8203bcfd03 This transform only handles two-operand AddRec's. Prevent it from trying to
handle anything more complex. Fixes PR10383 again!

llvm-svn: 139186
2011-09-06 21:42:18 +00:00
Nick Lewycky
e1c0b41d41 Fix typo in comment again.
llvm-svn: 139139
2011-09-06 07:02:40 +00:00
Nick Lewycky
700f71a0ac Apparently we compile the code, not the comments. Thanks Eli!
llvm-svn: 139138
2011-09-06 06:56:00 +00:00
Nick Lewycky
4add6eec38 Fix typo in comment.
llvm-svn: 139137
2011-09-06 06:46:01 +00:00
Nick Lewycky
0c9df5d6c2 Nope! I had it right the first time. Revert the operative part of r139135 and
add more showing of my work.

llvm-svn: 139136
2011-09-06 06:39:54 +00:00
Nick Lewycky
39b165bb7d Fix flipped sign. While there, show my math.
llvm-svn: 139135
2011-09-06 05:33:18 +00:00
Nick Lewycky
fdc650ea7a No no no, fix typo properly!
llvm-svn: 139134
2011-09-06 05:08:09 +00:00
Nick Lewycky
3823432a57 The logic inside getMulExpr to simplify {a,+,b}*{c,+,d} was wrong, which was
visible given a=b=c=d=1, on iteration #1 (the second iteration). Replace it with
correct math. Fixes PR10383!

llvm-svn: 139133
2011-09-06 05:05:14 +00:00