Add a check to catch violations. ~60 tests were broken and prevented
this change to be committed. Adrian and I (thanks Adrian!) went
through them in the last week or so updating. The check can be
done more efficiently but I'd still like to get this in ASAP to
avoid more broken tests to be checked in (if any).
PR: 27101
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266102 91177308-0d34-0410-b5e6-96231b3b80d8
This code was specific to vector operations with scalar operands:
all the opcodes in FoldValue (via FoldConstantArithmetic) can't
match those criteria.
Replace it with an assert if that ever changes: at that point,
we might need to add back a splat BUILD_VECTOR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266100 91177308-0d34-0410-b5e6-96231b3b80d8
Following up to a similar fix in MergeFunctions: r266022. This patch keeps both in sync, it would be nice to not have to do this. It doesn't look like there's an easy way to test this code directly at the moment: AFAICT all currect uses of isSameOperationAs are looking at instructions deep inside a function. IndVarSimplify/pr24952.ll and InstMerge/st_sink_* look at alloca inadvertently but are brittle tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266099 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor simplifications and code sharing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266098 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Under certain circumstances, multi-level breaks (or what is understood by
the control flow passes as such) could be miscompiled in a way that causes
infinite loops, by emitting incorrect control flow intrinsics.
This fixes a hang in
dEQP-GLES3.functional.shaders.loops.while_dynamic_iterations.conditional_continue_vertex
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18967
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266088 91177308-0d34-0410-b5e6-96231b3b80d8
This is a resubmittion of 263158 change.
This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace.
The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics.
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D17270
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266086 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In getUnderlyingObjectsForInstr(): Don't give up on instructions with
multiple MMOs, instead look through all the MMOs and if they all meet
the conservative criteria previously used for single MMO instructions,
then return all of the underlying objects derived from the MMOs.
The change to ScheduleDAGInstrs::buildSchedGraph() is needed to avoid
the case where multiple underlying objects are present and are related
in such a way that successive iterations of the loop end up adding a
dependency from an instruction to itself.
Reviewers: atrick, hfinkel
Subscribers: MatzeB, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18093
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266084 91177308-0d34-0410-b5e6-96231b3b80d8
These are different than atomicrmw add 1 because they have
an additional input value to clamp the result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266074 91177308-0d34-0410-b5e6-96231b3b80d8
When the memory vectorizer is enabled, these tests break.
These tests don't really care about the memory instructions,
and it's easier to write check lines with the unmerged loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266071 91177308-0d34-0410-b5e6-96231b3b80d8
They broke the msan bot.
Original message:
Add __atomic_* lowering to AtomicExpandPass.
AtomicExpandPass can now lower atomic load, atomic store, atomicrmw,and
cmpxchg instructions to __atomic_* library calls, when the target
doesn't support atomics of a given size.
This is the first step towards moving all atomic lowering from clang
into llvm. When all is done, the behavior of __sync_* builtins,
__atomic_* builtins, and C11 atomics will be unified.
Previously LLVM would pass everything through to the ISelLowering
code. There, unsupported atomic instructions would turn into __sync_*
library calls. Because of that behavior, Clang currently avoids emitting
llvm IR atomic instructions when this would happen, and emits __atomic_*
library functions itself, in the frontend.
This change makes LLVM able to emit __atomic_* libcalls, and thus will
eventually allow clang to depend on LLVM to do the right thing.
It is advantageous to do the new lowering to atomic libcalls in
AtomicExpandPass, before ISel time, because it's important that all
atomic operations for a given size either lower to __atomic_*
libcalls (which may use locks), or native instructions which won't. No
mixing and matching.
At the moment, this code is enabled only for SPARC, as a
demonstration. The next commit will expand support to all of the other
targets.
Differential Revision: http://reviews.llvm.org/D18200
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266062 91177308-0d34-0410-b5e6-96231b3b80d8
On z13, if eliminateFrameIndex() chooses LE (and not LEY), immediately
transform that LE to LDE32 to avoid partial register dependencies.
LEY should be generally preferred for big offsets over an expansion
into LAY + LDE32.
Reviewed by Ulrich Weigand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266060 91177308-0d34-0410-b5e6-96231b3b80d8
This is intended to be shared by the ThinLTOCodeGenerator.
Note that there is a change in the way the verifier is run, previously
it was ran as a Pass on the merged module during internalization.
While now the verifier is called explicitely on the merged module
outside of the internalize "pass pipeline".
What remains strange in the API is the fact that `DisableVerify` in
the API does not disable this initial verifier.
Differential Revision: http://reviews.llvm.org/D19000
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266047 91177308-0d34-0410-b5e6-96231b3b80d8
In the ELFv2 ABI, we are not required to save all CR fields. If only one
nonvolatile CR field is clobbered, use mfocrf instead of mfcr to
selectively save the field, because mfocrf has short latency compares to
mfcr.
Thanks Nemanja's invaluable hint!
Reviewers: nemanjai tjablin hfinkel kbarton
http://reviews.llvm.org/D17749
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266038 91177308-0d34-0410-b5e6-96231b3b80d8
`allocsize` is a function attribute that allows users to request that
LLVM treat arbitrary functions as allocation functions.
This patch makes LLVM accept the `allocsize` attribute, and makes
`@llvm.objectsize` recognize said attribute.
The review for this was split into two patches for ease of reviewing:
D18974 and D14933. As promised on the revisions, I'm landing both
patches as a single commit.
Differential Revision: http://reviews.llvm.org/D14933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266032 91177308-0d34-0410-b5e6-96231b3b80d8
Although repairing definitions is not mandatory for correctness (only
phis would be impacted because of the RPO traversal), not repairing
might go against the cost model. Therefore, just repair when it is
possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266025 91177308-0d34-0410-b5e6-96231b3b80d8
It may be convenient to know where we are about to insert some code, for
instance to save and then restore this insertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266024 91177308-0d34-0410-b5e6-96231b3b80d8
r237193 fix handling of alloca size / align in MergeFunctions, but only tested one and didn't follow FunctionComparator::cmpOperations's usual comparison pattern. It also didn't update Instruction.cpp:haveSameSpecialState which I'll do separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266022 91177308-0d34-0410-b5e6-96231b3b80d8
Use the MachineFunctionProperty mechanism to indicate whether the
liveness info is accurate instead of a bool flag on MRI.
Keeps the MRI accessor function for convenience. NFC
Differential Revision: http://reviews.llvm.org/D18767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266020 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't like implicitly calling the ArrayRef constructor with a
returned array -- it appears to decays the returned value to a pointer,
first, before trying to make an ArrayRef out of it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266011 91177308-0d34-0410-b5e6-96231b3b80d8
The call to processPHI already erased MI from its parent, so MI isn't
even valid here, making the getParent() call a use-after-free in
addition to being redundant.
Found by ASan with the ArrayRecycler changes in llvm.org/pr26808.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266008 91177308-0d34-0410-b5e6-96231b3b80d8
MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266007 91177308-0d34-0410-b5e6-96231b3b80d8
