- Recognize expressions like "x > -1 ? x : 0" as min/max and turn them
into expressions like "x < 0 ? 0 : x", which is easily recognizable
as a min/max operation.
- Refrain from folding expression like "y/2 < 1" to "y < 2" when the
comparison is being used as part of a min or max idiom, like
"y/2 < 1 ? 1 : y/2". In that case, the division has another use, so
folding doesn't eliminate it, and obfuscates the min/max, making it
harder to recognize as a min/max operation.
These benefit ScalarEvolution, CodeGen, and anything else that wants to
recognize integer min and max.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56246 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56196 91177308-0d34-0410-b5e6-96231b3b80d8
when a readonly declaration is called, set a
flag. This is faster and uses less memory.
In theory it is less accurate, because before
only those internal globals that were read
by someone were being marked "Ref", but now
all are. But in practice, thanks to other
passes, all internal globals of the kind
considered here will be both read and stored
to: those only read will have been turned
into constants, and those only stored to will
have been deleted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56143 91177308-0d34-0410-b5e6-96231b3b80d8
(1) code left over from the days of ConstantPointerRef:
if a use of a function is a GlobalValue then that is
not considered a reason to add an edge from the external
node, even though the use may be as an initializer for
an externally visible global! There might be some point
to this behaviour when the use is by an alias (though the
code predated aliases by some centuries), but I think
PR2782 is a better way of handling that. (2) If function
F calls function G, and also G is a parameter to the
call, then an F->G edge is not added to the callgraph.
While this doesn't seem to matter much, adding such an
edge makes the callgraph more regular.
In addition, the new code should be faster as well as
simpler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55987 91177308-0d34-0410-b5e6-96231b3b80d8
call (thus changing the call site) it didn't
inform the callgraph about this. But the
call site does matter - as shown by the testcase,
the callgraph become invalid after the inliner
ran (with an edge between two functions simply
missing), resulting in wrong deductions by
GlobalsModRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55872 91177308-0d34-0410-b5e6-96231b3b80d8
because it does not maintain a correct list
of callsites. I discovered (see following
commit) that the inliner will create a wrong
callgraph if it is fed a callgraph with
correct edges but incorrect callsites. These
were created by Prune-EH, and while it wasn't
done via removeCallEdgeTo, it could have been
done via removeCallEdgeTo, which is an accident
waiting to happen. Use removeCallEdgeFor
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55859 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55714 91177308-0d34-0410-b5e6-96231b3b80d8
doesNotAccessMemory, check doesNotAccessMemory
first, since otherwise functions may be
marked readonly rather than readnone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55697 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55696 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55263 91177308-0d34-0410-b5e6-96231b3b80d8
can have a non-negative result; for example, -16%16 is 0. Also,
clarify the related comments. This fixes PR2670.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54767 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54697 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54589 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54332 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54194 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54184 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54132 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53812 91177308-0d34-0410-b5e6-96231b3b80d8
