Commit Graph

837 Commits

Author SHA1 Message Date
Tobias Grosser
032d56baf2 Move delinearization from SCEVAddRecExpr to ScalarEvolution
The expressions we delinearize do not necessarily have to have a SCEVAddRecExpr
at the outermost level. At this moment, the additional flexibility  is not
exploited in LLVM itself, but in Polly we will soon soonish use this
functionality. For LLVM, this change should not affect existing functionality
(which is covered by test/Analysis/Delinearization/)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240952 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-29 14:42:48 +00:00
Alexander Kornienko
cd52a7a381 Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240390 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-23 09:49:53 +00:00
Alexander Kornienko
cf0db29df2 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240137 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-19 15:57:42 +00:00
Jingyue Wu
2703007b7b [ScalarEvolution] refactor: extract interface getGEPExpr
Summary:
This allows other passes (such as SLSR) to compute the SCEV expression for an
imaginary GEP.

Test Plan: no regression

Reviewers: atrick, sanjoy

Reviewed By: sanjoy

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D9786

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237589 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 17:03:25 +00:00
Brendon Cahoon
8b94db17a4 Fix a type mismatch assert in SCEV division
An assert was triggered when attempting to create a new SCEV
with operands of different types in the visitAddRecExpr. In this
test case, the operand types of the numerator and denominator
are different. The SCEV division code should generate a
conservative answer when this happens.

Differential Revision: http://reviews.llvm.org/D9021


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235511 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 15:06:40 +00:00
Brendon Cahoon
d9b36e1007 Recognize n/1 in the SCEV divide function
n/1 generates a quotient equal to n and a remainder of 0.
If this case is not recognized, then the SCEV divide() function
can return a remainder that is greater than or equal to the
denominator, which means the delinearized subscripts for the
test case will be incorrect.

Differential Revision: http://reviews.llvm.org/D9003


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235311 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-20 16:03:28 +00:00
David Blaikie
19443c1bcb [opaque pointer type] API migration for GEP constant factories
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233938 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-02 18:55:32 +00:00
Sanjoy Das
5436372079 [SCEV] Look at backedge dominating conditions (re-land r233447).
Summary:
This change teaches ScalarEvolution::isLoopBackedgeGuardedByCond to look
at edges within the loop body that dominate the latch.  We don't do an
exhaustive search for all possible edges, but only a quick walk up the
dom tree.

This re-lands r233447.  r233447 was reverted because it caused massive
compile-time regressions.  This change has a fix for the same issue.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233829 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-01 18:24:06 +00:00
Daniel Jasper
a4b389c125 Revert "[SCEV] Look at backedge dominating conditions."
This leads to terribly slow compile times under MSAN. More discussion
on the commit thread of r233447.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233529 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 09:30:02 +00:00
Sanjoy Das
e464bbfb5a [SCEV] Look at backedge dominating conditions.
Summary:
This change teaches ScalarEvolution::isLoopBackedgeGuardedByCond to look
at edges within the loop body that dominate the latch.  We don't do an
exhaustive search for all possible edges, but only a quick walk up the
dom tree.

Reviewers: atrick, hfinkel

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8627

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233447 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-27 23:18:08 +00:00
Sanjoy Das
a9228aa73b [SCEV] Revert bailout added in r75511.
Summary:
With the introduction of MarkPendingLoopPredicates in r157092, I don't
think the bailout is needed anymore.

Reviewers: atrick, nicholas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8624

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233296 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-26 17:28:26 +00:00
David Blaikie
63ccf14139 Refactor: Simplify boolean expressions in lib/Analysis
Simplify boolean expressions using `true` and `false` with `clang-tidy`

Patch by Richard Thomson.

Reviewed By: nlewycky

Differential Revision: http://reviews.llvm.org/D8528

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233091 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-24 16:33:19 +00:00
Nick Lewycky
9478751e46 Fix comment from r232794. NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232796 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-20 02:52:23 +00:00
Nick Lewycky
bea9b06e84 When simplifying a SCEV truncate by distributing, consider it a simplification to replace a cast, even if we end up with a trunc around the term. Fixes PR22960!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-20 02:25:00 +00:00
Sanjoy Das
e027d74733 [SCEV] Make isImpliedCond smarter.
Summary:
This change teaches isImpliedCond to infer things like "X sgt 0" => "X -
1 sgt -1".  The `ConstantRange` class has the logic to do the heavy
lifting, this change simply gets ScalarEvolution to exploit that when
reasonable.

Depends on D8345

Reviewers: atrick

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8346

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232576 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-18 00:41:29 +00:00
Nick Lewycky
011cb4d5bd When forming an addrec out of a phi don't just look at the last computation and steal its flags for our own, there may be other computations in the middle. Check whether the LHS of the computation is the phi itself and then we know it's safe to steal the flags. Fixes PR22795.
There's a missed optimization opportunity where we could look at the full chain of computation and take the intersection of the flags instead of only looking one instruction deep.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232134 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 01:37:52 +00:00
Mehdi Amini
529919ff31 DataLayout is mandatory, update the API to reflect it with references.
Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.

This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.

I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.

I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.

Test Plan:

Reviewers: echristo

Subscribers: llvm-commits

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231740 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 02:37:25 +00:00
Sanjoy Das
cd5029d001 [SCEV] Unify getUnsignedRange and getSignedRange
Summary:
This removes some duplicated code, and also helps optimization: e.g. in
the test case added, `%idx ULT 128` in `@x` is not currently optimized
to `true` by `-indvars` but will be, after this change.

The only functional change in ths commit is that for add recurrences,
ScalarEvolution::getRange will be more aggressive -- computing the
unsigned (resp. signed) range for a SCEVAddRecExpr will now look at the
NSW (resp. NUW) bits and check for signed (resp. unsigned) overflow.
This can be a strict improvement in some cases (such as the attached
test case), and should be no worse in other cases.

Reviewers: atrick, nlewycky

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8142

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231709 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-09 21:43:43 +00:00
Sanjoy Das
afeb9bf44e [SCEV] Add a `scalar-evolution-print-constant-ranges' option
Summary:
Unused in this commit, but will be used in a subsequent change (D8142)
by a FileCheck test.

Reviewers: atrick

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8143

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231708 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-09 21:43:39 +00:00
David Blaikie
da4471d726 Simplify expressions involving boolean constants with clang-tidy
Patch by Richard (legalize at xmission dot com).

Differential Revision: http://reviews.llvm.org/D8154

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231617 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-09 01:57:13 +00:00
NAKAMURA Takumi
d12ce78ca9 ScalarEvolution.cpp: Appease g++-4.7. He missed implicit "this" in lambda.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231331 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-05 01:02:45 +00:00
Sanjoy Das
12aa70b7e9 [SCEV] make SCEV smarter about proving no-wrap.
Summary:
Teach SCEV to prove no overflow for an add recurrence by proving
something about the range of another add recurrence a loop-invariant
distance away from it.

Reviewers: atrick, hfinkel

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7980

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231305 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-04 22:24:17 +00:00
Mehdi Amini
c94da20917 Make DataLayout Non-Optional in the Module
Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

Differential Revision: http://reviews.llvm.org/D7992

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231270 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-04 18:43:29 +00:00
Sanjoy Das
edf1700d33 Fix bug 22641
The bug was a result of getPreStartForExtend interpreting nsw/nuw
flags on an add recurrence more strongly than is legal.  {S,+,X}<nsw>
implies S+X is nsw only if the backedge of the loop is taken at least
once.

NOTE: I had accidentally committed an unrelated change with the commit
message of this change in r230275 (r230275 was reverted in r230279).
This is the correct change for this commit message.

Differential Revision: http://reviews.llvm.org/D7808



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230291 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-24 01:02:42 +00:00
Sanjoy Das
b2c7cf6d16 Address post commit review on r229600.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229646 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-18 08:03:22 +00:00
Sanjoy Das
00af5b5d50 Generalize getExtendAddRecStart to work with both sign and zero
extensions.

This change also removes `DEBUG(dbgs() << "SCEV: untested prestart
overflow check\n");` because that case has a unit test now.

Differential Revision: http://reviews.llvm.org/D7645



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229600 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-18 01:47:07 +00:00
Sanjoy Das
0afc9b33fe Bugfix: SCEV incorrectly marks certain expressions as nsw
I could not come up with a test case for this one; but I don't think
`getPreStartForSignExtend` can assume `AR` is `nsw` -- there is one
place in scalar evolution that calls `getSignExtendAddRecStart(AR,
...)` without proving that `AR` is `nsw`

(line 1564)

   OperandExtendedAdd =
     getAddExpr(WideStart,
                getMulExpr(WideMaxBECount,
                           getZeroExtendExpr(Step, WideTy)));
   if (SAdd == OperandExtendedAdd) {
     // If AR wraps around then
     //
     //    abs(Step) * MaxBECount > unsigned-max(AR->getType())
     // => SAdd != OperandExtendedAdd
     //
     // Thus (AR is not NW => SAdd != OperandExtendedAdd) <=>
     // (SAdd == OperandExtendedAdd => AR is NW)

     const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW);

     // Return the expression with the addrec on the outside.
     return getAddRecExpr(getSignExtendAddRecStart(AR, Ty, this),
                          getZeroExtendExpr(Step, Ty),
                          L, AR->getNoWrapFlags());
   }

Differential Revision: http://reviews.llvm.org/D7640



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229594 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-18 00:43:19 +00:00
Benjamin Kramer
1a50a12b43 Prefer SmallVector::append/insert over push_back loops.
Same functionality, but hoists the vector growth out of the loop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229500 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-17 15:29:18 +00:00
Sanjoy Das
2ceba77dfa Bugfix: SCEV incorrectly marks certain add recurrences as nsw
When creating a scev for sext({X,+,Y}), scev checks if the expression
is equivalent to {sext X,+,zext Y}.  If it can prove that, it also
tags the original {X,+,Y} as <nsw>, which is not correct.

In the test case I run `-scalar-evolution` twice because the bug
manifests only once SCEV has run through and seen the `sext`
expressions (and then does a in-place mutation on {X,+,Y}).

Differential Revision: http://reviews.llvm.org/D7495



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228586 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 18:34:55 +00:00
Johannes Doerfert
f8c4fd6005 Allow ScalarEvolution to catch more min/max cases
For the attached test case different types are used in the ICmpInst
  and SelectInst that represent the min/max expressions. However, if the
  ICmpInst type is smaller a comparison with the sign/zero extended
  operands would have yielded the same result. This situation might
  arise after the instruction combination pass was applied.

  Differential Revision: http://reviews.llvm.org/D7338


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228572 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 12:34:23 +00:00
Sanjoy Das
1af442e572 Bugfix: ScalarEvolution incorrectly assumes that the start of certain
add recurrences don't overflow.

This change makes the optimization more restrictive.  It still assumes
that an overflowing `add nsw` is undefined behavior; and this change
will need revisiting once we have a consistent semantics for poison
values.

Differential Revision: http://reviews.llvm.org/D7331



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228552 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-08 22:52:17 +00:00
Benjamin Kramer
0e0271af87 SCEV: Compress disposition pairs.
Composing DenseMaps and SmallVectors is still somewhat suboptimal,
but this at least halves the size of the vector elements. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228497 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-07 16:41:12 +00:00
Sanjoy Das
48fcc07856 Make ScalarEvolution less aggressive with respect to no-wrap flags.
ScalarEvolution currently lowers a subtraction recurrence to an add
recurrence with the same no-wrap flags as the subtraction.  This is
incorrect because `sub nsw X, Y` is not the same as `add nsw X, -Y`
and `sub nuw X, Y` is not the same as `add nuw X, -Y`.  This patch
fixes the issue, and adds two test cases demonstrating the bug.

Differential Revision: http://reviews.llvm.org/D7081



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226755 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-22 00:48:47 +00:00
Chandler Carruth
de5df29556 [PM] Split the LoopInfo object apart from the legacy pass, creating
a LoopInfoWrapperPass to wire the object up to the legacy pass manager.

This switches all the clients of LoopInfo over and paves the way to port
LoopInfo to the new pass manager. No functionality change is intended
with this iteration.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226373 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-17 14:16:18 +00:00
Chandler Carruth
eeeec3ce0d [PM] Separate the TargetLibraryInfo object from the immutable pass.
The pass is really just a means of accessing a cached instance of the
TargetLibraryInfo object, and this way we can re-use that object for the
new pass manager as its result.

Lots of delta, but nothing interesting happening here. This is the
common pattern that is developing to allow analyses to live in both the
old and new pass manager -- a wrapper pass in the old pass manager
emulates the separation intrinsic to the new pass manager between the
result and pass for analyses.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226157 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-15 10:41:28 +00:00
Chandler Carruth
bda134910a [PM] Move TargetLibraryInfo into the Analysis library.
While the term "Target" is in the name, it doesn't really have to do
with the LLVM Target library -- this isn't an abstraction which LLVM
targets generally need to implement or extend. It has much more to do
with modeling the various runtime libraries on different OSes and with
different runtime environments. The "target" in this sense is the more
general sense of a target of cross compilation.

This is in preparation for porting this analysis to the new pass
manager.

No functionality changed, and updates inbound for Clang and Polly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226078 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-15 02:16:27 +00:00
Sanjoy Das
7f0da20b97 Fix PR22179.
We were incorrectly inferring nsw for certain SCEVs. We can be more
aggressive here (see Richard Smith's comment on
http://llvm.org/bugs/show_bug.cgi?id=22179) but this change just
focuses on correctness.

Differential Revision: http://reviews.llvm.org/D6914



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225591 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-10 23:41:24 +00:00
Chandler Carruth
5a9cd4d44e [PM] Split the AssumptionTracker immutable pass into two separate APIs:
a cache of assumptions for a single function, and an immutable pass that
manages those caches.

The motivation for this change is two fold. Immutable analyses are
really hacks around the current pass manager design and don't exist in
the new design. This is usually OK, but it requires that the core logic
of an immutable pass be reasonably partitioned off from the pass logic.
This change does precisely that. As a consequence it also paves the way
for the *many* utility functions that deal in the assumptions to live in
both pass manager worlds by creating an separate non-pass object with
its own independent API that they all rely on. Now, the only bits of the
system that deal with the actual pass mechanics are those that actually
need to deal with the pass mechanics.

Once this separation is made, several simplifications become pretty
obvious in the assumption cache itself. Rather than using a set and
callback value handles, it can just be a vector of weak value handles.
The callers can easily skip the handles that are null, and eventually we
can wrap all of this up behind a filter iterator.

For now, this adds boiler plate to the various passes, but this kind of
boiler plate will end up making it possible to port these passes to the
new pass manager, and so it will end up factored away pretty reasonably.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225131 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-04 12:03:27 +00:00
Sanjoy Das
574e01c32e Teach ScalarEvolution to exploit min and max expressions when proving
isKnownPredicate.

The motivation for this change is to optimize away checks in loops
like this:

    limit = min(t, len)
    for (i = 0 to limit)
      if (i >= len || i < 0) throw_array_of_of_bounds();
      a[i] = ...

Differential Revision: http://reviews.llvm.org/D6635



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 22:50:15 +00:00
Mark Heffernan
b10837d169 Clarify HowFarToZero computation when the step is a positive power of two. Functionally this should be identical to the existing code except for the case where Step is maximally negative (eg, INT_MIN). We now punt in that one corner case to make reasoning about the code easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224274 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 21:19:53 +00:00
David Majnemer
fabf5cc5d9 ScalarEvolution: Remove SCEVUDivision, it's unused
This is just a code simplification, no functionality change is intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224216 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-14 09:12:33 +00:00
Mark Heffernan
1e9d355499 Fix PR21694. r219517 added a use of SCEV divide in HowFarToZero computation. This divide can produce incorrect results as we are using an unsigned divide for what should be a modular divide. This change reverts back to a more conservative computation using trailing zeros.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223974 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 22:53:52 +00:00
Duncan P. N. Exon Smith
dad20b2ae2 IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532.  Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.

I have a follow-up patch prepared for `clang`.  If this breaks other
sub-projects, I apologize in advance :(.  Help me compile it on Darwin
I'll try to fix it.  FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.

This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.

Here's a quick guide for updating your code:

  - `Metadata` is the root of a class hierarchy with three main classes:
    `MDNode`, `MDString`, and `ValueAsMetadata`.  It is distinct from
    the `Value` class hierarchy.  It is typeless -- i.e., instances do
    *not* have a `Type`.

  - `MDNode`'s operands are all `Metadata *` (instead of `Value *`).

  - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
    replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.

    If you're referring solely to resolved `MDNode`s -- post graph
    construction -- just use `MDNode*`.

  - `MDNode` (and the rest of `Metadata`) have only limited support for
    `replaceAllUsesWith()`.

    As long as an `MDNode` is pointing at a forward declaration -- the
    result of `MDNode::getTemporary()` -- it maintains a side map of its
    uses and can RAUW itself.  Once the forward declarations are fully
    resolved RAUW support is dropped on the ground.  This means that
    uniquing collisions on changing operands cause nodes to become
    "distinct".  (This already happened fairly commonly, whenever an
    operand went to null.)

    If you're constructing complex (non self-reference) `MDNode` cycles,
    you need to call `MDNode::resolveCycles()` on each node (or on a
    top-level node that somehow references all of the nodes).  Also,
    don't do that.  Metadata cycles (and the RAUW machinery needed to
    construct them) are expensive.

  - An `MDNode` can only refer to a `Constant` through a bridge called
    `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).

    As a side effect, accessing an operand of an `MDNode` that is known
    to be, e.g., `ConstantInt`, takes three steps: first, cast from
    `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
    third, cast down to `ConstantInt`.

    The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
    metadata schema owners transition away from using `Constant`s when
    the type isn't important (and they don't care about referring to
    `GlobalValue`s).

    In the meantime, I've added transitional API to the `mdconst`
    namespace that matches semantics with the old code, in order to
    avoid adding the error-prone three-step equivalent to every call
    site.  If your old code was:

        MDNode *N = foo();
        bar(isa             <ConstantInt>(N->getOperand(0)));
        baz(cast            <ConstantInt>(N->getOperand(1)));
        bak(cast_or_null    <ConstantInt>(N->getOperand(2)));
        bat(dyn_cast        <ConstantInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));

    you can trivially match its semantics with:

        MDNode *N = foo();
        bar(mdconst::hasa               <ConstantInt>(N->getOperand(0)));
        baz(mdconst::extract            <ConstantInt>(N->getOperand(1)));
        bak(mdconst::extract_or_null    <ConstantInt>(N->getOperand(2)));
        bat(mdconst::dyn_extract        <ConstantInt>(N->getOperand(3)));
        bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));

    and when you transition your metadata schema to `MDInt`:

        MDNode *N = foo();
        bar(isa             <MDInt>(N->getOperand(0)));
        baz(cast            <MDInt>(N->getOperand(1)));
        bak(cast_or_null    <MDInt>(N->getOperand(2)));
        bat(dyn_cast        <MDInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));

  - A `CallInst` -- specifically, intrinsic instructions -- can refer to
    metadata through a bridge called `MetadataAsValue`.  This is a
    subclass of `Value` where `getType()->isMetadataTy()`.

    `MetadataAsValue` is the *only* class that can legally refer to a
    `LocalAsMetadata`, which is a bridged form of non-`Constant` values
    like `Argument` and `Instruction`.  It can also refer to any other
    `Metadata` subclass.

(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
Nick Lewycky
8a51f8e8ce Canonicalize multiplies by looking at whether the operands have any constants themselves. Patch by Tim Murray!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223554 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 00:45:50 +00:00
David Blaikie
5401ba7099 Update SetVector to rely on the underlying set's insert to return a pair<iterator, bool>
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.

This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222334 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 07:49:26 +00:00
David Majnemer
2014c91510 ScalarEvolution: Construct SCEVDivision's Derived type instead of itself
SCEVDivision::divide constructed an object of SCEVDivision<Derived>
instead of Derived.  divide would call visit which would cast the
SCEVDivision<Derived> to type Derived.  As it happens,
SCEVDivision<Derived> and Derived currently have the same layout but
this is fragile and grounds for UB.

Instead, just construct Derived.  No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222126 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-17 11:27:45 +00:00
David Majnemer
2aad1e3567 ScalarEvolution: Introduce SCEVSDivision and SCEVUDivision
It turns out that not all users of SCEVDivision want the same
signedness.  Let the users determine which operation they'd like by
explicitly choosing SCEVUDivision or SCEVSDivision.

findArrayDimensions and computeAccessFunctions will use SCEVSDivision
while HowFarToZero will use SCEVUDivision.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222104 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-16 20:35:19 +00:00
David Majnemer
62baa594d7 ScalarEvolution: HowFarToZero was wrongly using signed division
HowFarToZero was supposed to use unsigned division in order to calculate
the backedge taken count.  However, SCEVDivision::divide performs signed
division.  Unless I am mistaken, no users of SCEVDivision actually want
signed arithmetic: switch to udiv and urem.

This fixes PR21578.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222093 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-16 07:30:35 +00:00
Sanjoy Das
de87c9165a Teach ScalarEvolution to sharpen range information.
If x is known to have the range [a, b), in a loop predicated by (icmp
ne x, a) its range can be sharpened to [a + 1, b).  Get
ScalarEvolution and hence IndVars to exploit this fact.

This change triggers an optimization to widen-loop-comp.ll, so it had
to be edited to get it to pass.

This change was originally landed in r219834 but had a bug and broke
ASan. It was reverted in r219878, and is now being re-landed after
fixing the original bug.

phabricator: http://reviews.llvm.org/D5639
reviewed by: atrick



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221839 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-13 00:00:58 +00:00
Duncan P. N. Exon Smith
5bf8ade9d0 Revert "IR: MDNode => Value"
Instead, we're going to separate metadata from the Value hierarchy.  See
PR21532.

This reverts commit r221375.
This reverts commit r221373.
This reverts commit r221359.
This reverts commit r221167.
This reverts commit r221027.
This reverts commit r221024.
This reverts commit r221023.
This reverts commit r220995.
This reverts commit r220994.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221711 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 21:30:22 +00:00