for alignment into the LSDA. If the TType base offset is emitted, then put the
padding there. Otherwise, put it in the call site table length. There will be no
conflict between the two sites when placing the padding in one place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97277 91177308-0d34-0410-b5e6-96231b3b80d8
o Parallel addition and subtraction, signed/unsigned
o Miscellaneous operations: QADD, QDADD, QSUB, QDSUB
o Unsigned sum of absolute differences [and accumulate]: USAD8, USADA8
o Signed/Unsigned saturate: SSAT, SSAT16, USAT, USAT16
o Signed multiply accumulate long (halfwords): SMLAL<x><y>
o Signed multiply accumulate/subtract [long] (dual): SMLAD[x], SMLALD[X], SMLSD[X], SMLSLD[X]
o Signed dual multiply add/subtract [long]: SMUAD[X], SMUSD[X]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97276 91177308-0d34-0410-b5e6-96231b3b80d8
This is possible because F8RC is a subclass of F4RC. We keep FMRSD around so
fextend has a pattern.
Also allow folding of memory operands on FMRSD.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97275 91177308-0d34-0410-b5e6-96231b3b80d8
longer than 80 columns. This replaces the heavy-handed "textwidth"
mechanism, and makes the trailing-whitespace highlighting lazy so
that it isn't constantly jumping on the user during typing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97267 91177308-0d34-0410-b5e6-96231b3b80d8
The PowerPC floating point registers can represent both f32 and f64 via the
two register classes F4RC and F8RC. F8RC is considered a subclass of F4RC to
allow cross-class coalescing. This coalescing only affects whether registers
are spilled as f32 or f64.
Spill slots must be accessed with load/store instructions corresponding to the
class of the spilled register. PPCInstrInfo::foldMemoryOperandImpl was looking
at the instruction opcode which is wrong.
X86 has similar floating point register classes, but doesn't try to fold
memory operands, so there is no problem there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97262 91177308-0d34-0410-b5e6-96231b3b80d8
Previously LoopStrengthReduce would sometimes be unable to find
a legal formula, causing an assertion failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97226 91177308-0d34-0410-b5e6-96231b3b80d8
gross little neighbor merging implementation. This one has
the benefit of not violating the ordering of patterns, so it
generates code that passes tests again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97218 91177308-0d34-0410-b5e6-96231b3b80d8
current design. This generates a matcher that successfully
runs, but it turns out that the factoring we're doing violates
the ordering of patterns, so we end up matching (e.g.) movups
where we want movaps. This won't due, but I'll address this in
a follow on patch. It's nice to not be on by default yet! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97215 91177308-0d34-0410-b5e6-96231b3b80d8
object construction. There is no provision to change them when the
code for a function generated.
So we have to change these names while printing assembly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97213 91177308-0d34-0410-b5e6-96231b3b80d8
and restore the entire matcher stack by value. This is because children
we're testing could do moveparent or other things besides just
scribbling on additions to the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97212 91177308-0d34-0410-b5e6-96231b3b80d8
the alignment requirement, if it no longer makes the TType base offset overflow
into extra bytes, then we need to pad to those bytes ourselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97196 91177308-0d34-0410-b5e6-96231b3b80d8
