Commit Graph

5202 Commits

Author SHA1 Message Date
David Majnemer
597e1ab1aa ValueTracking: Small cleanup in ComputeNumSignBits
Constant contains the isAllOnesValue and isNullValue predicates, not
ConstantInt.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224848 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-26 09:20:17 +00:00
Michael Kuperstein
a098c770e1 [ValueTracking] Move GlobalAlias handling to be after the max depth check in computeKnownBits()
GlobalAlias handling used to be after GlobalValue handling, which meant it was, in practice, dead code. r220165 moved GlobalAlias handling to be before GlobalValue handling, but also moved it to be before the max depth check, causing an assert due to a recursion depth limit violation. 

This moves GlobalAlias handling forward to where it's safe, and changes the GlobalValue handling to only look at GlobalObjects.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224765 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-23 11:33:41 +00:00
David Majnemer
821c6f765a InstSimplify: Don't bother if getScalarSizeInBits returns zero
getScalarSizeInBits returns zero when the comparison operands are not
integral.  No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224675 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-20 04:45:33 +00:00
David Majnemer
f666c0549e Simplify the code
No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224673 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-20 03:29:59 +00:00
David Majnemer
9cd99a0724 InstSimplify: Optimize away pointless comparisons
(X & INT_MIN) ? X & INT_MAX : X  into  X & INT_MAX
(X & INT_MIN) ? X : X & INT_MAX  into  X
(X & INT_MIN) ? X | INT_MIN : X  into  X
(X & INT_MIN) ? X : X | INT_MIN  into  X | INT_MIN

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224669 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-20 03:04:38 +00:00
Tilmann Scheller
6500a9867f Remove redundant assignment.
Found with the Clang static analyzer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224570 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-19 11:29:34 +00:00
David Majnemer
891ec6d69f InstSimplify: shl nsw/nuw undef, %V -> undef
We can always choose an value for undef which might cause %V to shift
out an important bit except for one case, when %V is zero.

However, shl behaves like an identity function when the right hand side
is zero.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224405 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-17 01:54:33 +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
Elena Demikhovsky
2f6d42351a Sink store based on alias analysis
- by Ella Bolshinsky
The alias analysis is used define whether the given instruction
is a barrier for store sinking. For 2 identical stores, following
instructions are checked in the both basic blocks, to determine
whether they are sinking barriers.

http://reviews.llvm.org/D6420



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224247 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 14:09:53 +00:00
Elena Demikhovsky
1c3a1516f8 Loop Vectorizer minor changes in the code -
some comments, function names, identation.

Reviewed here: http://reviews.llvm.org/D6527


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-14 09:43:50 +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
David Majnemer
3b7e6d27d2 ValueTracking: Don't recurse too deeply in computeKnownBitsFromAssume
Respect the MaxDepth recursion limit, doing otherwise will trigger an
assert in computeKnownBits.

This fixes PR21891.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224168 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-12 23:59:29 +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
David Majnemer
72c6bdbf70 ConstantFold, InstSimplify: undef >>a x can be either -1 or 0, choose 0
Zero is usually a nicer constant to have than -1.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223969 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 21:58:15 +00:00
David Majnemer
6578f1beb1 InstSimplify: [al]shr exact undef, %X -> undef
Exact shifts always keep the non-zero bits of their input.  This means
it keeps it's undef bits.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223923 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 09:14:52 +00:00
David Majnemer
1297775557 InstSimplify: div %X, 0 -> undef
We already optimized rem %X, 0 to undef, we should do the same for div.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223919 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 07:52:18 +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
David Majnemer
fca9c7b21c InstSimplify: Try to bring back the rest of r223583
This reverts r223624 with a small tweak, hopefully this will make stage3
equivalent.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223679 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-08 18:30:43 +00:00
NAKAMURA Takumi
e4a5390406 Revert a part of r223583, for now. It seems causing different emission between stage2(gcc-clang) and stage3 clang. Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223624 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-08 02:07:22 +00:00
David Majnemer
620e8763ec InstSimplify: Optimize away useless unsigned comparisons
Code like X < Y && Y == 0 should always be folded away to false.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223583 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 10:51:40 +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
Duncan P. N. Exon Smith
1a283409bc BFI: Saturate when combining edges to a successor
When a loop gets bundled up, its outgoing edges are quite large, and can
just barely overflow 64-bits.  If one successor has multiple incoming
edges -- and that successor is getting all the incoming mass --
combining just its edges can overflow.  Handle that by saturating rather
than asserting.

This fixes PR21622.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223500 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-05 19:13:42 +00:00
Hal Finkel
efbb95a1be Revert "r223364 - Revert r223347 which has caused crashes on bootstrap bots."
Reapply r223347, with a fix to not crash on uninserted instructions (or more
precisely, instructions in uninserted blocks). bugpoint was able to reduce the
test case somewhat, but it is still somewhat large (and relies on setting
things up to be simplified during inlining), so I've not included it here.
Nevertheless, it is clear what is going on and why.

Original commit message:

Restrict somewhat the memory-allocation pointer cmp opt from r223093

Based on review comments from Richard Smith, restrict this optimization from
applying to globals that might resolve lazily to other dynamically-loaded
modules, and also from dynamic allocas (which might be transformed into malloc
calls). In short, take extra care that the compared-to pointer is really
simultaneously live with the memory allocation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223371 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 17:45:19 +00:00
Alexander Potapenko
182d9aaccb Revert r223347 which has caused crashes on bootstrap bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223364 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 14:22:27 +00:00
Elena Demikhovsky
73ae1df82c Masked Load / Store Intrinsics - the CodeGen part.
I'm recommiting the codegen part of the patch.
The vectorizer part will be send to review again.

Masked Vector Load and Store Intrinsics.
Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores.
Added SDNodes for masked operations and lowering patterns for X86 code generator.
Examples:
<16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask)
declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask)

Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch.

http://reviews.llvm.org/D6191



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223348 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 09:40:44 +00:00
Hal Finkel
d70d5148a6 Restrict somewhat the memory-allocation pointer cmp opt from r223093
Based on review comments from Richard Smith, restrict this optimization from
applying to globals that might resolve lazily to other dynamically-loaded
modules, and also from dynamic allocas (which might be transformed into malloc
calls). In short, take extra care that the compared-to pointer is really
simultaneously live with the memory allocation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223347 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 09:22:28 +00:00
Hal Finkel
7e32aa1015 Simplify pointer comparisons involving memory allocation functions
System memory allocation functions, which are identified at the IR level by the
noalias attribute on the return value, must return a pointer into a memory region
disjoint from any other memory accessible to the caller. We can use this
property to simplify pointer comparisons between allocated memory and local
stack addresses and the addresses of global variables. Neither the stack nor
global variables can overlap with the region used by the memory allocator.

Fixes PR21556.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223093 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 23:38:06 +00:00
Philip Reames
204e21b51a [Statepoints 1/4] Statepoint infrastructure for garbage collection: IR Intrinsics
The statepoint intrinsics are intended to enable precise root tracking through the compiler as to support garbage collectors of all types. The addition of the statepoint intrinsics to LLVM should have no impact on the compilation of any program which does not contain them. There are no side tables created, no extra metadata, and no inhibited optimizations.

A statepoint works by transforming a call site (or safepoint poll site) into an explicit relocation operation. It is the frontend's responsibility (or eventually the safepoint insertion pass we've developed, but that's not part of this patch series) to ensure that any live pointer to a GC object is correctly added to the statepoint and explicitly relocated. The relocated value is just a normal SSA value (as seen by the optimizer), so merges of relocated and unrelocated values are just normal phis. The explicit relocation operation, the fact the statepoint is assumed to clobber all memory, and the optimizers standard semantics ensure that the relocations flow through IR optimizations correctly.

This is the first patch in a small series.  This patch contains only the IR parts; the documentation and backend support will be following separately.  The entire series can be seen as one combined whole in http://reviews.llvm.org/D5683.

Reviewed by: atrick, ributzka





git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223078 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 21:18:12 +00:00
Rafael Espindola
6c8ce66b03 Relax an assert a bit to avoid a crash on unreachable code.
Patch by Duncan Exon Smith with a small tweak by me.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222984 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 02:55:24 +00:00
Duncan P. N. Exon Smith
54786a0936 Revert "Masked Vector Load and Store Intrinsics."
This reverts commit r222632 (and follow-up r222636), which caused a host
of LNT failures on an internal bot.  I'll respond to the commit on the
list with a reproduction of one of the failures.

Conflicts:
	lib/Target/X86/X86TargetTransformInfo.cpp

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222936 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-28 21:29:14 +00:00
David Majnemer
f45536e75e InstSimplify: Restore optimizations lost in r210006
This restores our ability to optimize:
(X & C) ? X & ~C : X  into  X & ~C
(X & C) ? X : X & ~C  into  X
(X & C) ? X | C : X  into  X
(X & C) ? X : X | C  into  X | C

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222868 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-27 06:32:46 +00:00
Hans Wennborg
4d48c3f1aa LazyValueInfo: Actually re-visit partially solved block-values in solveBlockValue()
If solveBlockValue() needs results from predecessors that are not already
computed, it returns false with the intention of resuming when the dependencies
have been resolved. However, the computation would never be resumed since an
'overdefined' result had been placed in the cache, preventing any further
computation.

The point of placing the 'overdefined' result in the cache seems to have been
to break cycles, but we can check for that when inserting work items in the
BlockValue stack instead. This makes the "stop and resume" mechanism of
solveBlockValue() work as intended, unlocking more analysis.

Using this patch shaves 120 KB off a 64-bit Chromium build on Linux.

I benchmarked compiling bzip2.c at -O2 but couldn't measure any difference in
compile time.

Tests by Jiangning Liu from r215343 / PR21238, Pete Cooper, and me.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222768 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-25 17:23:05 +00:00
Chandler Carruth
a87c35420b Revert r220349 to re-instate r220277 with a fix for PR21330 -- quite
clearly only exactly equal width ptrtoint and inttoptr casts are no-op
casts, it says so right there in the langref. Make the code agree.

Original log from r220277:
Teach the load analysis to allow finding available values which require
inttoptr or ptrtoint cast provided there is datalayout available.
Eventually, the datalayout can just be required but in practice it will
always be there today.

To go with the ability to expose available values requiring a ptrtoint
or inttoptr cast, helpers are added to perform one of these three casts.

These smarts are necessary to finish canonicalizing loads and stores to
the operational type requirements without regressing fundamental
combines.

I've added some test cases. These should actually improve as the load
combining and store combining improves, but they may fundamentally be
highlighting some missing combines for select in addition to exercising
the specific added logic to load analysis.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222739 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-25 08:20:27 +00:00
David Majnemer
044b644f54 InstSimplify: Handle some simple tautological comparisons
This handles cases where we are comparing a masked value against itself.
The analysis could be further improved by making it recursive but such
expense is not currently justified.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222716 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-25 02:55:48 +00:00
Philip Reames
521c9dc7d8 Factor check for the assume intrinsic out of checks in computeKnownBitsFromAssume
We were matching against the assume intrinsic in every check.  Since we know that it must be an assume, this is just wasted work.  Somewhat surprisingly, matching an intrinsic id is actually relatively expensive.  It devolves to a string construction and comparison in Function::isIntrinsic.

I originally spotted this because it showed up in a performance profile of my compiler.  I've since discovered a separate issue which seems to be the actual root cause, but this is minor perf goodness regardless.  

I'm likely to follow up with another change to factor out the comparison matching.  There's no need to match the compare instruction in every single one of the tests.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222709 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 23:44:28 +00:00
Rafael Espindola
7fe9d46f39 Remove the unused FindUsedTypes pass.
It was dead since r134829.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222684 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 20:53:26 +00:00
Rafael Espindola
468d2fc5ca Add and use Type::subtypes. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222682 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 20:44:36 +00:00
Elena Demikhovsky
ae1ae2c3a1 Masked Vector Load and Store Intrinsics.
Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores.
Added SDNodes for masked operations and lowering patterns for X86 code generator.
Examples:
<16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask)
declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask)

Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch.

http://reviews.llvm.org/D6191



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222632 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-23 08:07:43 +00:00
David Majnemer
7eca618dfc InstSimplify: Simplify (sub 0, X) -> X if it's NUW
This is a generalization of the X - (0 - Y) -> X transform.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222611 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-22 07:15:16 +00:00
Hans Wennborg
b4401e33d5 LazyValueInfo: range'ify some for-loops. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222557 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-21 19:07:46 +00:00
Hans Wennborg
36c3fc5ddc LazyValueInfo: fix some typos and indentation, etc. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222554 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-21 18:58:23 +00:00
David Majnemer
a44c501561 AliasSet: Simplify mergeSetIn
No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222376 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 19:36:18 +00:00
David Majnemer
f47d325eec AliasSetTracker: UnknownInsts should contribute to the refcount
AliasSetTracker::addUnknown may create an AliasSet devoid of pointers
just to contain an instruction if no suitable AliasSet already exists.
It will then AliasSet::addUnknownInst and we will be done.

However, it's possible for addUnknown to choose an existing AliasSet to
addUnknownInst.
If this were to occur, we are in a bit of a pickle: removing pointers
from the AliasSet can cause the entire AliasSet to become destroyed,
taking our unknown instructions out with them.

Instead, keep track whether or not our AliasSet has any unknown
instructions.

This fixes PR21582.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222338 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 09:41:05 +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
Jingyue Wu
ec3cfb00dc [DependenceAnalysis] Allow subscripts of different types
Summary:
Several places in DependenceAnalysis assumes both SCEVs in a subscript pair
share the same integer type. For instance, isKnownPredicate calls
SE->getMinusSCEV(X, Y) which asserts X and Y share the same type. However,
DependenceAnalysis fails to ensure this assumption when producing a subscript
pair, causing tests such as NonCanonicalizedSubscript to crash. With this
patch, DependenceAnalysis runs unifySubscriptType before producing any
subscript pair, ensuring the assumption.

Test Plan:
Added NonCanonicalizedSubscript.ll on which DependenceAnalysis before the fix
crashed because subscripts have different types.

Reviewers: spop, sebpop, jingyue

Reviewed By: jingyue

Subscribers: eliben, meheff, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222100 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-16 16:52:44 +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
David Majnemer
f5dc5ae36b InstSimplify: Optimize ICmpInst xform that uses computeKnownBits
A few things:
- computeKnownBits is relatively expensive, let's delay its use as long
  as we can.
- Don't create two APInt values just to run computeKnownBits on a
  ConstantInt, we already know the exact value!
- Avoid creating a temporary APInt value in order to calculate unary
  negation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222092 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-16 02:20:08 +00:00