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
Add StackProtector to SafeStack. This adds limited protection against
data corruption in the caller frame. Current implementation treats
all stack protector levels as -fstack-protector-all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266004 91177308-0d34-0410-b5e6-96231b3b80d8
This is better for a few reasons:
+ It matches the other tooling for iOS.
+ It matches EABI in more cases (i.e. Thumb-mode, and in practice we don't
use ARM mode).
+ It leads to infinitesimally smaller code (0.2%, yay!).
rdar://25369506
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266003 91177308-0d34-0410-b5e6-96231b3b80d8
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@266002 91177308-0d34-0410-b5e6-96231b3b80d8
xor/and/or (bitcast(A), bitcast(B)) -> bitcast(op (A,B)) was only being combined at the AfterLegalizeTypes stage, this patch permits the combine to occur anytime before then as well.
The main aim with this to improve the ability to recognise bitmasks that can be converted to shuffles.
I had to modify a number of AVX512 mask tests as the basic bitcast to/from scalar pattern was being stripped out, preventing testing of the mmask bitops. By replacing the bitcasts with loads we can get almost the same result.
Differential Revision: http://reviews.llvm.org/D18944
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265998 91177308-0d34-0410-b5e6-96231b3b80d8
We were incorrectly reporting all non-64 bit integers as int64s.
This is most evident when trying to print the "short" type, but
in theory could happen with chars too (although usually chars use
a different builtin type).
Additionally, we were using the wrong check when deciding whether
to print an enum definition as a global enum. We were checking
whether or not the enum was "nested", and if so saving it until
we print the class definition that it was nested in. But this is
not correct in rare situations where the enum is nested, but the
class that it's nested in does not have type information in the PDB.
So instead we check if there is a class definition for the parent
in the PDB. If so we save it for later, otherwise we print it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265993 91177308-0d34-0410-b5e6-96231b3b80d8
Before, ELF at least managed a diagnostic but it was a completely untraceable
"undefined symbol" error. MachO had a variety of even worse behaviours: crash,
emit corrupt file, or an equally bad message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265984 91177308-0d34-0410-b5e6-96231b3b80d8
This patch ensures that when we detect first-order recurrences, we reject a phi
node if its previous value is also a phi node. During vectorization the initial
and previous values of the recurrence are shuffled together to create the value
for the current iteration. However, phi nodes are not widened like other
instructions. This fixes PR27246.
Differential Revision: http://reviews.llvm.org/D18971
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265983 91177308-0d34-0410-b5e6-96231b3b80d8
MachineFrameInfo does not need to be able to distinguish between the
user asking us not to realign the stack and the target telling us it
doesn't support stack realignment. Either way, fixed stack objects have
their alignment clamped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265971 91177308-0d34-0410-b5e6-96231b3b80d8
