| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 137881
|
|
|
|
|
|
|
|
|
|
| |
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!)
llvm-svn: 137880
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137879
|
|
|
|
|
|
|
|
| |
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!)
llvm-svn: 137876
|
|
|
|
| |
llvm-svn: 137875
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137873
|
|
|
|
| |
llvm-svn: 137872
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137871
|
|
|
|
|
|
| |
so requires more care than this generic algorithm should handle.
llvm-svn: 137866
|
|
|
|
| |
llvm-svn: 137865
|
|
|
|
| |
llvm-svn: 137864
|
|
|
|
|
|
| |
instruction should be marked as potentially reading and/or writing memory.
llvm-svn: 137863
|
|
|
|
| |
llvm-svn: 137857
|
|
|
|
| |
llvm-svn: 137856
|
|
|
|
|
|
|
|
| |
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'.
llvm-svn: 137855
|
|
|
|
|
|
| |
is clearly impossible given the current structure of the code.
llvm-svn: 137853
|
|
|
|
| |
llvm-svn: 137848
|
|
|
|
| |
llvm-svn: 137844
|
|
|
|
|
|
| |
the OpInfo array.
llvm-svn: 137838
|
|
|
|
|
|
|
|
|
|
| |
here, be a bit more defensive
with unknown instructions.
Fixes PR10687.
llvm-svn: 137836
|
|
|
|
|
|
| |
Bruno's comment.
llvm-svn: 137831
|
|
|
|
|
|
|
|
| |
instruction that is disassemblable, but invalid. Only used for ARM UNPREDICTABLE instructions at the moment.
Patch by James Molloy.
llvm-svn: 137830
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137810
|
|
|
|
| |
llvm-svn: 137808
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 137807
|
|
|
|
| |
llvm-svn: 137804
|
|
|
|
| |
llvm-svn: 137798
|
|
|
|
|
|
| |
library. Preparation for upcoming (preliminary) support for plugins for the static analyzer.
llvm-svn: 137791
|
|
|
|
| |
llvm-svn: 137788
|
|
|
|
|
|
| |
do not, for the purposes of decoding them.
llvm-svn: 137787
|
|
|
|
|
|
| |
how to actually trigger the codepath in question at the moment, but it might get exposed in the future.
llvm-svn: 137781
|
|
|
|
| |
llvm-svn: 137779
|
|
|
|
|
|
|
|
| |
This simplified handling of these needs in dwarf writer. However, one side effect of this is that during link time optimization all these MDNodes are _not_ uniqued. In other words there will be N number of MDNodes describing "int", "char" and all other types, which would suddenly grow when each object file starts using libraries like STL.
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.
llvm-svn: 137778
|
|
|
|
|
|
|
|
|
| |
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".
llvm-svn: 137777
|
|
|
|
| |
llvm-svn: 137774
|
|
|
|
| |
llvm-svn: 137759
|
|
|
|
| |
llvm-svn: 137757
|
|
|
|
| |
llvm-svn: 137756
|
|
|
|
|
|
| |
this with a normal pass pipeline, but fixing for completeness.)
llvm-svn: 137755
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137746
|
|
|
|
|
|
| |
check for a LandingPadInst.
llvm-svn: 137745
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 137744
|
|
|
|
| |
llvm-svn: 137743
|
|
|
|
|
|
| |
The argument is unused, and is a layering violation in any case.
llvm-svn: 137735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 137733
|
|
|
|
| |
llvm-svn: 137728
|
|
|
|
|
|
| |
Patch by Kristof Beyls and James Malloy.
llvm-svn: 137723
|
|
|
|
| |
llvm-svn: 137719
|
|
|
|
|
|
|
|
| |
ends can use without needing to be aware of the plugin (or the plugin be aware of the front end).
Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file. API suggestions welcome...
llvm-svn: 137717
|
|
|
|
| |
llvm-svn: 137712
|