The landingpad instruction is lowered into the EXCEPTIONADDR and EHSELECTION
SDNodes. The information from the landingpad instruction is harvested by the
'AddLandingPadInfo' function. The new EH uses the current EH scheme in the
back-end. This will change once we switch over to the new scheme. (Reviewed by
Jakob!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137880 91177308-0d34-0410-b5e6-96231b3b80d8
Represent the operand value as it will be encoded in the instruction. This
allows removing the specialized encoder and decoder methods entirely. Add
an assembler match class while we're at it to lay groundwork for parsing the
thumb shift instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137879 91177308-0d34-0410-b5e6-96231b3b80d8
PRE needs the landing pads to have their critical edges split. Doing this for a
landing pad is non-trivial. Abandon the attempt to perform PRE when we come
across a landing pad. (Reviewed by Owen!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137876 91177308-0d34-0410-b5e6-96231b3b80d8
This generates the SDNodes for the new exception handling scheme. It takes the
two values coming from the landingpad instruction and assigns them to the
EXCEPTIONADDR and EHSELECTION nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137873 91177308-0d34-0410-b5e6-96231b3b80d8
One way to exit the loop is through an unwind edge. However, that may involve
splitting the critical edge of the landing pad, which is non-trivial. Prevent
the transformation from rewriting the landing pad exit loop block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137871 91177308-0d34-0410-b5e6-96231b3b80d8
Things are much saner now. We no longer need to modify the laning pads, because
of the invariants we impose upon them. The only thing DwarfEHPrepare needs to do
is convert the 'resume' instruction into a call to '_Unwind_Resume'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137855 91177308-0d34-0410-b5e6-96231b3b80d8
match splats in the form (splat (scalar_to_vector (load ...))) whenever
the load can be folded. All the logic and instruction emission is
working but because of PR8156, there are no ways to match loads, cause
they can never be folded for splats. Thus, the tests are XFAILed, but
I've tested and exercised all the logic using a relaxed version for
checking the foldable loads, as if the bug was already fixed. This
should work out of the box once PR8156 gets fixed since MayFoldLoad will
work as expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137810 91177308-0d34-0410-b5e6-96231b3b80d8
vinsertf128 $1 + vpermilps $0, remove the old code that used to first
do the splat in a 128-bit vector and then insert it into a larger one.
This is better because the handling code gets simpler and also makes a
better room for the upcoming vbroadcast!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137807 91177308-0d34-0410-b5e6-96231b3b80d8
MDNodes graph structure such that compiler unit keeps track of important MDNodes and update dwarf writer to process mdnodes top-down instead of bottom up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137778 91177308-0d34-0410-b5e6-96231b3b80d8
making random bad assumptions about instructions which are not explicitly listed.
Includes fix for rdar://9956541, a version of "undef ^ undef should return
0 because it's easier than arguing with users".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137777 91177308-0d34-0410-b5e6-96231b3b80d8
Thumb one requires that many arithmetic instruction forms have an 'S'
suffix. For Thumb2, the whether the suffix is required or precluded depends
on whether the instruction is in an IT block. Use target parser predicates
to check for these sorts of context-sensitive constraints.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137746 91177308-0d34-0410-b5e6-96231b3b80d8
getFirstInsertionPt() returns an iterator to the first insertion point in a
basic block. This is after all PHIs and any other instruction which is required
to be at the top of the basic block (like LandingPadInst).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137744 91177308-0d34-0410-b5e6-96231b3b80d8
there is no support for native 256-bit shuffles, be more smart in some
cases, for example, when you can extract specific 128-bit parts and use
regular 128-bit shuffles for them. Example:
For this shuffle:
shufflevector <4 x i64> %a, <4 x i64> %b, <4 x i32>
<i32 1, i32 0, i32 7, i32 6>
This was expanded to:
vextractf128 $1, %ymm1, %xmm2
vpextrq $0, %xmm2, %rax
vmovd %rax, %xmm1
vpextrq $1, %xmm2, %rax
vmovd %rax, %xmm2
vpunpcklqdq %xmm1, %xmm2, %xmm1
vpextrq $0, %xmm0, %rax
vmovd %rax, %xmm2
vpextrq $1, %xmm0, %rax
vmovd %rax, %xmm0
vpunpcklqdq %xmm2, %xmm0, %xmm0
vinsertf128 $1, %xmm1, %ymm0, %ymm0
ret
Now we get:
vshufpd $1, %xmm0, %xmm0, %xmm0
vextractf128 $1, %ymm1, %xmm1
vshufpd $1, %xmm1, %xmm1, %xmm1
vinsertf128 $1, %xmm1, %ymm0, %ymm0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137733 91177308-0d34-0410-b5e6-96231b3b80d8
Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file. API suggestions welcome...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137717 91177308-0d34-0410-b5e6-96231b3b80d8
Mips1 does not support double precision loads or stores, therefore two single
precision loads or stores must be used in place of these instructions. This
patch treats double precision loads and stores as if they are legal
instructions until MCInstLowering, instead of generating the single precision
instructions during instruction selection or Prolog/Epilog code insertion.
Without the changes made in this patch, llc produces code that has the same
problem described in r137484 or bails out when
MipsInstrInfo::storeRegToStackSlot or loadRegFromStackSlot is called before
register allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137711 91177308-0d34-0410-b5e6-96231b3b80d8
