| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 137742
|
| |
|
|
|
|
| |
The argument is unused, and is a layering violation in any case.
llvm-svn: 137735
|
| |
|
|
| |
llvm-svn: 137734
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 137725
|
| |
|
|
|
|
| |
Patch by Kristof Beyls and James Malloy.
llvm-svn: 137723
|
| |
|
|
| |
llvm-svn: 137721
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
Thanks to Jonas Gafele for noticing.
llvm-svn: 137716
|
| |
|
|
| |
llvm-svn: 137715
|
| |
|
|
| |
llvm-svn: 137712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 137711
|
| |
|
|
| |
llvm-svn: 137707
|
| |
|
|
| |
llvm-svn: 137706
|
| |
|
|
| |
llvm-svn: 137703
|
| |
|
|
|
|
| |
load/store.
llvm-svn: 137702
|
| |
|
|
|
|
| |
FileCheckize. It is more properly an optimizer test.
llvm-svn: 137700
|
| |
|
|
|
|
| |
to be wrong (or at least somewhat suspect). Leave a FIXME for Bill.
llvm-svn: 137694
|
| |
|
|
| |
llvm-svn: 137693
|
| |
|
|
|
|
|
|
| |
This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it. I think the current behavior is correct,
though. Bill, can you double-check that?
llvm-svn: 137691
|
| |
|
|
| |
llvm-svn: 137690
|
| |
|
|
| |
llvm-svn: 137689
|
| |
|
|
| |
llvm-svn: 137687
|
| |
|
|
|
|
| |
Thumb2 NEON decoding hooks to bring us closer to correctness.
llvm-svn: 137686
|
| |
|
|
|
|
| |
also add the AVX versions of the 128-bit patterns
llvm-svn: 137685
|
| |
|
|
|
|
|
| |
predicate and TB encoding fields. This fix the encoding for the
attached testcase. This fixes PR10625.
llvm-svn: 137684
|
| |
|
|
|
|
| |
uses of getCompileUnit().
llvm-svn: 137683
|
| |
|
|
|
|
|
|
|
|
| |
It turns out that the use of "__extension__" in these macros was disabling
the expected "incompatible pointer" warnings, so these type checks were not
doing anything anyway. They introduced a serious bug by evaluating some
macro arguments twice, which is a big problem for arguments with side effects.
I'll have to find another way to get the right type checking. Radar 9947657.
llvm-svn: 137680
|
| |
|
|
|
|
| |
if necessary.
llvm-svn: 137679
|
| |
|
|
|
|
|
|
| |
Allow a target assembly parser to do context sensitive constraint checking
on a potential instruction match. This will be used, for example, to handle
Thumb2 IT block parsing.
llvm-svn: 137675
|
| |
|
|
| |
llvm-svn: 137673
|
| |
|
|
| |
llvm-svn: 137672
|
| |
|
|
|
|
| |
possible.
llvm-svn: 137668
|
| |
|
|
| |
llvm-svn: 137667
|
| |
|
|
| |
llvm-svn: 137664
|
| |
|
|
|
|
| |
variable.
llvm-svn: 137663
|
| |
|
|
|
|
| |
is a bit unusual.
llvm-svn: 137662
|
| |
|
|
|
|
|
| |
when AVX mode is one. Otherwise is just more work for the type
legalizer.
llvm-svn: 137661
|
| |
|
|
|
|
| |
location expressions. In such cases, AT_location attribute's value will be a label.
llvm-svn: 137659
|
| |
|
|
| |
llvm-svn: 137658
|
| |
|
|
| |
llvm-svn: 137657
|
| |
|
|
|
|
| |
instruction.
llvm-svn: 137656
|
| |
|
|
|
|
| |
write to memory.) Marking it as such makes some checks for immobility go away.
llvm-svn: 137655
|
| |
|
|
|
|
| |
Simon Moll on llvmdev.
llvm-svn: 137654
|
| |
|
|
| |
llvm-svn: 137652
|
| |
|
|
| |
llvm-svn: 137651
|