| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 205732
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving these patterns from TableGen files to PerformDAGCombine()
should allow us to generate better code by eliminating unnecessary
shifts and extensions earlier.
This also fixes a bug where the MAD pattern was calling
SimplifyDemandedBits with a 24-bit mask on the first operand
even when the full pattern wasn't being matched. This occasionally
resulted in some instructions being incorrectly deleted from the
program.
v2:
- Fix bug with 64-bit mul
llvm-svn: 205731
|
| |
|
|
| |
llvm-svn: 205730
|
| |
|
|
| |
llvm-svn: 205723
|
| |
|
|
| |
llvm-svn: 205722
|
| |
|
|
|
|
|
| |
Makes iteration over implicit and explicit machine operands more
explicit (har har). Insipired by code review discussion for r205565.
llvm-svn: 205680
|
| |
|
|
| |
llvm-svn: 205648
|
| |
|
|
| |
llvm-svn: 205610
|
| |
|
|
|
|
|
|
|
|
|
| |
Acording to AMD documentation, the correct opcode for
BFE_INT is 0x5, not 0x4
Fixes Arithm/Absdiff.Mat/3 OpenCV test
Patch by: Bruno Jiménez
llvm-svn: 205562
|
| |
|
|
| |
llvm-svn: 205561
|
| |
|
|
|
|
|
| |
It's now matched to the scalar 64-bit or and split later if
necessary.'
llvm-svn: 205252
|
| |
|
|
|
|
| |
Pass the entire vector type, and not just the element.
llvm-svn: 205247
|
| |
|
|
| |
llvm-svn: 205244
|
| |
|
|
| |
llvm-svn: 205242
|
| |
|
|
| |
llvm-svn: 205236
|
| |
|
|
| |
llvm-svn: 205235
|
| |
|
|
| |
llvm-svn: 205188
|
| |
|
|
|
|
|
| |
This allows allows us to replace ISD::EXTRACT_ELEMENT, which is lowered
using shifts, with ISD::EXTRACT_VECTOR_ELT, which is a no-op.
llvm-svn: 205187
|
| |
|
|
|
|
| |
The register index is stored in the low 8-bits of the encoding.
llvm-svn: 205186
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started trying to fix a small issue, but this code has seen a small fix too
many.
The old code was fairly convoluted. Some of the issues it had:
* It failed to check if a symbol difference was in the some section when
converting a relocation to pcrel.
* It failed to check if the relocation was already pcrel.
* The pcrel value computation was wrong in some cases (relocation-pc.s)
* It was missing quiet a few cases where it should not convert symbol
relocations to section relocations, leaving the backends to patch it up.
* It would not propagate the fact that it had changed a relocation to pcrel,
requiring a quiet nasty work around in ARM.
* It was missing comments.
llvm-svn: 205076
|
| |
|
|
|
|
|
|
| |
This was causing my llc to go into an infinite loop on
CodeGen/R600/address-space.ll (just triggered recently by some allocator
changes).
llvm-svn: 205005
|
| |
|
|
| |
llvm-svn: 204961
|
| |
|
|
| |
llvm-svn: 204956
|
| |
|
|
|
|
|
| |
This allows 64-bit operations that are truncated to be reduced
to 32-bit ones.
llvm-svn: 204946
|
| |
|
|
| |
llvm-svn: 204945
|
| |
|
|
|
|
| |
This sext_inreg i32 in i64 case was already handled, but not enabled.
llvm-svn: 204840
|
| |
|
|
|
|
|
|
| |
Remove handling of select_cc, since it makes no sense to be there. This
now does nothing, but I'll be adding some handling of other target nodes
soon.
llvm-svn: 204743
|
| |
|
|
|
|
|
| |
Having these popping up every time you use -debug is really
irritating.
llvm-svn: 204664
|
| |
|
|
|
|
|
| |
Check the register class of each operand individually
to avoid an extra copy to a vgpr.
llvm-svn: 204662
|
| |
|
|
|
|
|
| |
No longer asserts, but now you get moves loading legal immediates
into the split 32-bit operations.
llvm-svn: 204661
|
| |
|
|
|
|
|
|
| |
Try to match scalar and first like the other instructions.
Expand 64-bit ands to a pair of 32-bit ands since that is not
available on the VALU.
llvm-svn: 204660
|
| |
|
|
| |
llvm-svn: 204658
|
| |
|
|
| |
llvm-svn: 204651
|
| |
|
|
| |
llvm-svn: 204630
|
| |
|
|
| |
llvm-svn: 204618
|
| |
|
|
|
|
|
| |
This type promotion is replacing a Tablegen pattern and it is already
covered by existing tests.
llvm-svn: 204617
|
| |
|
|
|
|
| |
Each GPU family now has its own file.
llvm-svn: 204615
|
| |
|
|
|
|
|
| |
Some of them also had the pattern on both, so this removes the
duplication.
llvm-svn: 204492
|
| |
|
|
| |
llvm-svn: 204476
|
| |
|
|
| |
llvm-svn: 204475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SReg_(32|64) register classes contain special registers in addition
to the numbered SGPRs. This can lead to machine verifier errors when
these register classes are used as sub-registers for SReg_128, since
SReg_128 only uses the numbered SGPRs.
Replacing SReg_(32|64) with SGPR_(32|64) fixes this problem, since
the SGPR_(32|64) register classes contain only numbered SGPRs.
Tests cases for this are comming in a later commit.
llvm-svn: 204474
|
| |
|
|
| |
llvm-svn: 204357
|
| |
|
|
| |
llvm-svn: 204275
|
| |
|
|
| |
llvm-svn: 204274
|
| |
|
|
|
|
|
| |
v2:
-Use correct opcode for DS_READ_64
llvm-svn: 204273
|
| |
|
|
| |
llvm-svn: 204272
|
| |
|
|
|
|
|
|
| |
It isn't actually used now, and probably never will be, plus it makes
tests less annoying. I also think SC prints GDS instructions as a
separate instruction name.
llvm-svn: 204270
|
| |
|
|
|
|
|
|
|
| |
Also remove unused data fields from the DS_Load_Helper class.
v2:
- Merge fields for DS_WRITE
llvm-svn: 204269
|
| |
|
|
| |
llvm-svn: 204085
|
| |
|
|
| |
llvm-svn: 204072
|