have 4 bits per register in the operand encoding), but have undefined
behavior when the operand value is 13 or 15 (SP and PC, respectively).
The trivial coalescer in linear scan sometimes will merge a copy from
SP into a subsequent instruction which uses the copy, and if that
instruction cannot legally reference SP, we get bad code such as:
mls r0,r9,r0,sp
instead of:
mov r2, sp
mls r0, r9, r0, r2
This patch adds a new register class for use by Thumb2 that excludes
the problematic registers (SP and PC) and is used instead of GPR
for those operands which cannot legally reference PC or SP. The
trivial coalescer explicitly requires that the register class
of the destination for the COPY instruction contain the source
register for the COPY to be considered for coalescing. This prevents
errant instructions like that above.
PR7499
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109842 91177308-0d34-0410-b5e6-96231b3b80d8
integers with mov + vdup. 8003375. This is
currently disabled by default because LICM will
not hoist a VDUP, so it pessimizes the code if
the construct occurs inside a loop (8248029).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109799 91177308-0d34-0410-b5e6-96231b3b80d8
message is properly contaminated with nonsense about timing passes
that doesn't apply at all to this utility. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109769 91177308-0d34-0410-b5e6-96231b3b80d8
We do sometimes load from a too small stack slot when dealing with x86 arguments
(varargs and smaller-than-32-bit args). It looks like we know what we are doing
in those cases, so I am going to remove the assert instead of artifically
enlarging stack slot sizes.
The assert in storeRegToStackSlot stays in. We don't want to write beyond the
bounds of a stack slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109764 91177308-0d34-0410-b5e6-96231b3b80d8
it establishes a context and does a complaining diff. Also make sure we
unify the prelude and postlude of a diff after a block-diff call.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109744 91177308-0d34-0410-b5e6-96231b3b80d8
any differences we see. This should only happen if there are "non-structural"
differences between the instructions, i.e. differences which wouldn't cause
diff to return true.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109742 91177308-0d34-0410-b5e6-96231b3b80d8
in despite not ever incrementing any path costs, so that the only nonzero costs
arose from the all-left path in the first column. Anyway. Perform the diff
starting from the beginning of the block to avoid capturing (say) loads of
allocas.
Vastly improves diff results on code that hasn't been mem2reg'ed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109741 91177308-0d34-0410-b5e6-96231b3b80d8
diff of a function. There's a lot of cruft in the current version, and
it's pretty far from perfect, but it's usable.
Currently only capable of comparing functions. Currently ignores metadata.
Currently ignores most attributes of functions and instructions.
Patches welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109739 91177308-0d34-0410-b5e6-96231b3b80d8
- This works, but won't handle crashes on stack overflow, or signals delivered
to a thread other than the one that crashed. The latter is particular annoying
on Darwin, because SIGABRT tends to go to the main thread.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109717 91177308-0d34-0410-b5e6-96231b3b80d8
multiple defs, like t2LDRSB_POST.
The first def could accidentally steal the physreg that the second, tied def was
required to be allocated to.
Now, the tied use-def is treated more like an early clobber, and the physreg is
reserved before allocating the other defs.
This would never be a problem when the tied def was the only def which is the
usual case.
This fixes MallocBench/gs for thumb2 -O0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109715 91177308-0d34-0410-b5e6-96231b3b80d8
extend it to handle the case where multiple RAUWs affect a single
SCEVUnknown.
Add a ScalarEvolution unittest to test for this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109705 91177308-0d34-0410-b5e6-96231b3b80d8
The size of this object isn't used for anything - technically it is of variable
size.
This avoids a false positive from the assert in
X86InstrInfo::loadRegFromStackSlot, and fixes PR7735.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109652 91177308-0d34-0410-b5e6-96231b3b80d8