Add support for decoding VZEXT_MOVL target shuffle masks, allowing it to be used as a source in target shuffle combines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258215 91177308-0d34-0410-b5e6-96231b3b80d8
I think I fixed all instances of this in the codebase
(r258202, 258200, 258190). Also, the suppression didn't
have an effect on bots using make anyways, and it looks
like many bots still use configure/make bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258210 91177308-0d34-0410-b5e6-96231b3b80d8
As vector shuffles can only reference two inputs many (V)INSERTPS patterns end up being split over two targets shuffles.
This patch adds combines to attempt to combine (V)INSERTPS nodes with input/output nodes that are just zeroing out these additional vector elements.
Differential Revision: http://reviews.llvm.org/D16072
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258205 91177308-0d34-0410-b5e6-96231b3b80d8
r100895 landed an llvm-only change to add minix support to googletest.
It did that by putting "defined()" in a macro, which has undefined
behavior. Slightly reshuffle things to remove that undefined behavior.
Also mention in README.LLVM that minix support is a local change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258190 91177308-0d34-0410-b5e6-96231b3b80d8
they're needed.
Prior to this patch objects were loaded (via RuntimeDyld::loadObject) when they
were added to the ObjectLinkingLayer, but were not relocated and finalized until
a symbol address was requested. In the interim, another object could be loaded
and finalized with the same memory manager, causing relocation/finalization of
the first object to fail (as the first finalization call may have marked the
allocated memory for the first object read-only).
By deferring the loadObject call (and subsequent memory allocations) until an
object file is needed we can avoid prematurely finalizing memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258185 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases, the max backedge taken count can be more conservative
than the exact backedge taken count (for instance, because
ScalarEvolution::getRange is not control-flow sensitive whereas
computeExitLimitFromICmp can be). In these cases,
computeExitLimitFromCond (specifically the bit that deals with `and` and
`or` instructions) can create an ExitLimit instance with a
`SCEVCouldNotCompute` max backedge count expression, but a computable
exact backedge count expression. This violates an implicit SCEV
assumption: a computable exact BE count should imply a computable max BE
count.
This change
- Makes the above implicit invariant explicit by adding an assert to
ExitLimit's constructor
- Changes `computeExitLimitFromCond` to be more robust around
conservative max backedge counts
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258184 91177308-0d34-0410-b5e6-96231b3b80d8
Note: There are no uses of these functions outside of
SimplifyLibCalls, so they could be static functions in
that file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258172 91177308-0d34-0410-b5e6-96231b3b80d8
According the build bots, clang is using the Registry class somewhere as well. Will reapply with appropriate clang changes at a later point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258159 91177308-0d34-0410-b5e6-96231b3b80d8
The Registry class constructs a linked list of nodes whose storage is inside static variables and nodes are added via static initializers. The trick is that those static initializers are in both the LLVM code base, and some random plugin that might get loaded in at runtime. The existing code tries to use C++ templates and their ODR rules to get a single definition of the registry for each type, but, experimentally, this doesn't quite work as designed. (Well, the entire structure doesn't. It might not actually be an ODR problem.)
Previously, when I tried moving the GCStrategy class (along with it's registry) from CodeGen to IR, I ran into a problem where asking the GCStrategyRegistry a question would return inconsistent results depending on whether you asked from CodeGen (where the static initializers still were) or Transforms. My best guess is that this is a result of either a) an order of initialization error, or b) we ended up with two copies of the registry being created. I remember at the time having convinced myself it was probably (b), but I don't have any of my notes around from that investigation any more.
See http://reviews.llvm.org/rL226311 for the original patch in question.
This patch tries to remove the possibility of (b) above. (a) was already fixed in change 258109.
Differential Revision: http://reviews.llvm.org/D16170
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258157 91177308-0d34-0410-b5e6-96231b3b80d8
Our loop construct is not a way to identify cycles in the CFG. This wasn't immediately obvious from the header, so clarify that fact.
The motivation for this was that I just fixed a out of tree bug due to a mistaken assumption (on my part) on what a Loop actually was. While it was fresh in my mind, I wanted to document the key point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258154 91177308-0d34-0410-b5e6-96231b3b80d8
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
As with D15937, the intent of the patch is to preserve the current behavior of the transform
except that we use the pow call's 'fast' attribute as a trigger rather than a function-level
attribute.
The TODO comment notes a potential follow-on patch that would propagate FMF to the new
instructions.
Differential Revision: http://reviews.llvm.org/D16122
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258153 91177308-0d34-0410-b5e6-96231b3b80d8
This brings the pr26208 testcase down to 3.2 seconds. Not checking it in
since it does create a 4GB .o file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258149 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
add_version_info_from_vcs was setting SVN_REVISION to the last fetched
svn revision when using git svn instead of the svn revision
corresponding to HEAD. This leads to conflicts with the definition of
SVN_REVISION in SVNVersion.inc generated by GetSVN.cmake when HEAD is
not the most recently fetched svn revision.
Use 'git svn info' to determine SVN_REVISION when git svn is being used
instead (as is done in GetSVN.cmake).
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16299
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258148 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GEPOperator: provide getResultElementType alongside getSourceElementType.
This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has.
GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType.
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16275
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258145 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the register stackifier to rematerialize constants that have multiple
uses instead of leaving them in registers. In the WebAssembly encoding, it's
the same code size to materialize most constants as it is to read a value
from a register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258142 91177308-0d34-0410-b5e6-96231b3b80d8
The value size was always 1 or 0, so we don't need to store it.
In a no asserts build this takes the testcase of pr26208 from 11 to 10
seconds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258141 91177308-0d34-0410-b5e6-96231b3b80d8
