Commit Graph

5 Commits

Author SHA1 Message Date
Edward O'Callaghan f96ce30236 Convert Analysis tests to FileCheck in regards to PR5307.
llvm-svn: 85241
2009-10-27 14:54:46 +00:00
Dan Gohman 1880092722 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.

llvm-svn: 81537
2009-09-11 18:01:28 +00:00
Dan Gohman 9737a63ed8 Change these tests to feed the assembly files to opt directly, instead
of using llvm-as, now that opt supports this.

llvm-svn: 81226
2009-09-08 16:50:01 +00:00
Dan Gohman 81313fd8d1 Fix WriteAsOperand to not emit a leading space character. Adjust
its callers to emit a space character before calling it when a
space is needed.

This fixes several spurious whitespace issues in
ScalarEvolution's debug dumps. See the test changes for
examples.

This also fixes odd space-after-tab indentation in the output
for switch statements, and changes calls from being printed like
this:
  call void @foo( i32 %x )
to this:
  call void @foo(i32 %x)

llvm-svn: 56196
2008-09-14 17:21:12 +00:00
Eli Friedman 61f67624c3 PR2621: Improvements to the SCEV AddRec binomial expansion. This
version uses a new algorithm for evaluating the binomial coefficients 
which is significantly more efficient for AddRecs of more than 2 terms 
(see the comments in the code for details on how the algorithm works).  
It also fixes some bugs: it removes the arbitrary length restriction for 
AddRecs, it fixes the silent generation of incorrect code for AddRecs 
which require a wide calculation width, and it fixes an issue where we 
were incorrectly truncating the iteration count too far when evaluating 
an AddRec expression narrower than the induction variable.

There are still a few related issues I know of: I think there's 
still an issue with the SCEVExpander expansion of AddRec in terms of
the width of the induction variable used.  The hack to avoid generating 
too-wide integers shouldn't be necessary; instead, the callers should be 
considering the cost of the expansion before expanding it (in addition 
to not expanding too-wide integers, we might not want to expand 
expressions that are really expensive, especially when optimizing for 
size; calculating an length-17 32-bit AddRec currently generates about 250 
instructions of straight-line code on X86).  Also, for long 32-bit 
AddRecs on X86, CodeGen really sucks at scheduling the code.  I'm planning on 
filing follow-up PRs for these issues.

llvm-svn: 54332
2008-08-04 23:49:06 +00:00