| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 55779
|
| |
|
|
|
|
|
|
|
|
| |
analysis would bail out without removing function
records for other members of the SCC (which may exist
if those functions read or wrote global variables).
Since these are initialized to "readnone", this
resulted in incorrect alias analysis results.
llvm-svn: 55714
|
| |
|
|
| |
llvm-svn: 55700
|
| |
|
|
|
|
|
|
| |
doesNotAccessMemory, check doesNotAccessMemory
first, since otherwise functions may be
marked readonly rather than readnone.
llvm-svn: 55697
|
| |
|
|
|
|
|
|
|
|
|
| |
callgraph, when one member of a SCC calls another
then the analysis would drop to mod-ref because
there is (usually) no function info for the callee
yet; fix this. Teach the analysis about function
attributes, in particular the readonly attribute
(which requires being careful about globals).
llvm-svn: 55696
|
| |
|
|
| |
llvm-svn: 55508
|
| |
|
|
|
|
| |
Prakash Prabhu!
llvm-svn: 55458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use raw_ostream instead of std::ostream. Among other goodness,
this speeds up llvm-dis of kc++ with a release build from 0.85s
to 0.49s (88% faster).
Other interesting changes:
1) This makes Value::print be non-virtual.
2) AP[S]Int and ConstantRange can no longer print to ostream directly,
use raw_ostream instead.
3) This fixes a bug in raw_os_ostream where it didn't flush itself
when destroyed.
4) This adds a new SDNode::print method, instead of only allowing "dump".
A lot of APIs have both std::ostream and raw_ostream versions, it would
be useful to go through and systematically anihilate the std::ostream
versions.
This passes dejagnu, but there may be minor fallout, plz let me know if
so and I'll fix it.
llvm-svn: 55263
|
| |
|
|
|
|
| |
infinite loop.
llvm-svn: 55149
|
| |
|
|
|
|
| |
minimum of the known zeros.
llvm-svn: 55137
|
| |
|
|
| |
llvm-svn: 54977
|
| |
|
|
|
|
| |
deprecated for almost a year; it's finally time for them to go away.
llvm-svn: 54822
|
| |
|
|
|
|
|
| |
can have a non-negative result; for example, -16%16 is 0. Also,
clarify the related comments. This fixes PR2670.
llvm-svn: 54767
|
| |
|
|
|
|
|
| |
ptrtoint can be turned into a bitcast if the
integer is at least as wide as a pointer.
llvm-svn: 54752
|
| |
|
|
|
|
|
|
| |
continue past the first conditional branch when looking for a
relevant test. This helps it avoid using MAX expressions in
loop trip counts in more cases.
llvm-svn: 54697
|
| |
|
|
|
|
|
|
|
| |
type lattice value for an Argument*, giving clients the opportunity to
use something other than Top for it if they choose to."
Patch by John McCall!
llvm-svn: 54589
|
| |
|
|
| |
llvm-svn: 54545
|
| |
|
|
|
|
| |
up the passmgr by avoiding useless work.
llvm-svn: 54528
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
time applying to the implicit comparison in smin expressions. The
correct way to transform an inequality into the opposite
inequality, either signed or unsigned, is with a not expression.
I looked through the SCEV code, and I don't think there are any more
occurrences of this issue.
llvm-svn: 54194
|
| |
|
|
|
|
|
|
|
|
|
|
| |
SGT exit condition. Essentially, the correct way to flip an inequality
in 2's complement is the not operator, not the negation operator.
That said, the difference only affects cases involving INT_MIN.
Also, enhance the pre-test search logic to be a bit smarter about
inequalities flipped with a not operator, so it can eliminate the smax
from the iteration count for simple loops.
llvm-svn: 54184
|
| |
|
|
|
|
|
|
| |
circumstances we could end up remapping a dependee to the same instruction
that we're trying to remove. Handle this properly by just falling back to
a conservative solution.
llvm-svn: 54132
|
| |
|
|
| |
llvm-svn: 54030
|
| |
|
|
| |
llvm-svn: 53816
|
| |
|
|
|
|
|
|
|
|
| |
bail after 256-bits to avoid producing code that the backends can't handle.
Previously, we capped it at 64-bits, preferring to miscompile in those cases.
This change also reverts much of r52248 because the invariants the code was
expecting are now being met.
llvm-svn: 53812
|
| |
|
|
| |
llvm-svn: 53811
|
| |
|
|
|
|
| |
count.
llvm-svn: 53810
|
| |
|
|
|
|
|
|
| |
also use *idx_begin in the same expression, giving unpredictable results.
This fixes this bug: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-July/015877.html
llvm-svn: 53670
|
| |
|
|
|
|
| |
I swear that didn't show up in svn diff...
llvm-svn: 53587
|
| |
|
|
| |
llvm-svn: 53586
|
| |
|
|
|
|
| |
started complicating many loops ('for' loops, in fact).
llvm-svn: 53508
|
| |
|
|
| |
llvm-svn: 53489
|
| |
|
|
| |
llvm-svn: 53474
|
| |
|
|
|
|
| |
more complete version is now available from the LoopVR pass.
llvm-svn: 53269
|
| |
|
|
| |
llvm-svn: 53217
|
| |
|
|
|
|
| |
Comment the xor %x, -1 case.
llvm-svn: 53167
|
| |
|
|
| |
llvm-svn: 53088
|
| |
|
|
|
|
| |
unreachable blocks.
llvm-svn: 53032
|
| |
|
|
|
|
| |
Thanks for the feedback!
llvm-svn: 52978
|
| |
|
|
| |
llvm-svn: 52967
|
| |
|
|
|
|
|
|
| |
unreachable.
This fixes PR2503, though we should also fix other passes not to emit this kind of code.
llvm-svn: 52946
|
| |
|
|
|
|
|
|
| |
empty string for ConstantAggregateZero case which surprises selectiondag.
- Correctly handle memcpy from constant string which is zero-initialized.
llvm-svn: 52891
|
| |
|
|
| |
llvm-svn: 52885
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move GetConstantStringInfo to lib/Analysis. Remove
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
This unbreaks llvm-gcc bootstrap.
llvm-svn: 52884
|
| |
|
|
|
|
|
| |
GetConstantStringInfo. This will hopefully restore llvm-gcc to
happy bootstrap land.
llvm-svn: 52851
|
| |
|
|
| |
llvm-svn: 52850
|
| |
|
|
|
|
|
| |
tolerate a non-nul-terminated string, and handling a direct global
reference.
llvm-svn: 52813
|
| |
|
|
| |
llvm-svn: 52763
|
| |
|
|
|
|
|
|
|
| |
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
llvm-svn: 52748
|
| |
|
|
|
|
| |
ConstantExprs.
llvm-svn: 52615
|