| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Patch by Kristof Beyls and James Malloy.
llvm-svn: 137723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
when AVX mode is one. Otherwise is just more work for the type
legalizer.
llvm-svn: 137661
|
| |
|
|
|
|
|
|
| |
mode. Update tests to reflect this fact.
Patch by James Molloy.
llvm-svn: 137647
|
| |
|
|
| |
llvm-svn: 137643
|
| |
|
|
| |
llvm-svn: 137641
|
| |
|
|
| |
llvm-svn: 137636
|
| |
|
|
|
|
| |
comprehensive NEON decoding testcase.
llvm-svn: 137635
|
| |
|
|
| |
llvm-svn: 137615
|
| |
|
|
|
|
|
| |
Apparently we never added code to expand these pseudo instructions, and in
over a year, no one has noticed. Our register allocator must be awesome!
llvm-svn: 137551
|
| |
|
|
|
|
|
|
|
| |
Tidy up the code a bit and push the definition of the value next to the uses
to try to minimize this sort of issue from arising again while I'm at it.
rdar://9945172
llvm-svn: 137525
|
| |
|
|
| |
llvm-svn: 137521
|
| |
|
|
|
|
|
|
| |
vectors. It operates on 128-bit elements instead of regular scalar
types. Recognize shuffles that are suitable for VPERM2F128 and teach
the x86 legalizer how to handle them.
llvm-svn: 137519
|
| |
|
|
| |
llvm-svn: 137518
|
| |
|
|
| |
llvm-svn: 137515
|
| |
|
|
|
|
| |
Partial fix for rdar://9945172.
llvm-svn: 137513
|
| |
|
|
|
|
| |
add another batch of tests.
llvm-svn: 137502
|
| |
|
|
| |
llvm-svn: 137499
|
| |
|
|
|
|
| |
from certain USAT16 encodings.
llvm-svn: 137494
|
| |
|
|
| |
llvm-svn: 137487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer register to a floating point register. It is not valid to interpret
the value of a floating pointer register as part of a double precision
floating point value after a single precision floating point computational
or move instruction stores its result to the register.
- In the test case, the following code is generated before this patch is
applied:
mtc1 $zero, $f2 ; unformatted copy to $f2
mov.s $f0, $f2 ; $f0 is in single format
sdc1 $f12, 0($sp)
mov.s $f1, $f2 ; $f1 is in single format
c.eq.d $f12, $f0 ; $f0 cannot be interpreted as double
- The following code is generated after this patch is applied:
mtc1 $zero, $f0 ; unformatted copy to $f0
mtc1 $zero, $f1 ; unformatted copy to $f1
c.eq.d $f12, $f0 ; $f0 can be interpreted as double
Bhanu Chetlapalli and Chris Dearman at MIPS technologies reported this bug and
provided the test case.
llvm-svn: 137484
|
| |
|
|
| |
llvm-svn: 137481
|
| |
|
|
| |
llvm-svn: 137476
|
| |
|
|
|
|
| |
when building with assertions disabled.
llvm-svn: 137460
|
| |
|
|
|
|
| |
Fix by Ivan Baev. Sorry I don't have a unit test, but the fix is obvious so I don't want to delay it.
llvm-svn: 137404
|
| |
|
|
| |
llvm-svn: 137389
|
| |
|
|
|
|
| |
warning.
llvm-svn: 137378
|
| |
|
|
| |
llvm-svn: 137375
|
| |
|
|
| |
llvm-svn: 137372
|
| |
|
|
| |
llvm-svn: 137371
|
| |
|
|
| |
llvm-svn: 137370
|
| |
|
|
| |
llvm-svn: 137368
|
| |
|
|
| |
llvm-svn: 137367
|
| |
|
|
| |
llvm-svn: 137364
|
| |
|
|
| |
llvm-svn: 137363
|
| |
|
|
|
|
|
| |
inserts and extracts. This simple combine makes us generate only 1
instruction instead of 11 in the v8 case.
llvm-svn: 137362
|
| |
|
|
| |
llvm-svn: 137359
|
| |
|
|
| |
llvm-svn: 137356
|
| |
|
|
| |
llvm-svn: 137353
|
| |
|
|
| |
llvm-svn: 137351
|
| |
|
|
| |
llvm-svn: 137347
|
| |
|
|
| |
llvm-svn: 137345
|