| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 206498
|
|
|
|
|
|
| |
Otherwise we may not legalize some illegal REG_SEQUENCE instructions.
llvm-svn: 206497
|
|
|
|
| |
llvm-svn: 206475
|
|
|
|
| |
llvm-svn: 206437
|
|
|
|
| |
llvm-svn: 206357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting vector types to expand will result in scalarization on pre SI hw,
as those gpus don't have vector shifts either.
Expand also i32 vectors, this helps llvm make the correct decision
about scalarizing the vector ops.
v2: move setOperation() calls to R600ISelLowering.cpp.
cleanup the SI code to make it obvious that this patch does is nop for SI
Patch by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 206348
|
|
|
|
| |
llvm-svn: 206336
|
|
|
|
|
|
|
|
|
| |
Print in decimal for inline immediates, and hex otherwise. Use hex
always for offsets in addressing offsets.
This approximately matches what the shader compiler does.
llvm-svn: 206335
|
|
|
|
|
|
| |
Try to figure out the class and number of subregisters.
llvm-svn: 206334
|
|
|
|
| |
llvm-svn: 206330
|
|
|
|
|
|
| |
its own tree containing FixedStackPseudoSourceValue (which you can use isa/dyn_cast on) and MipsCallEntry (which you can't). Anything that needs to use either a PseudoSourceValue* and Value* is strongly encouraged to use a MachinePointerInfo instead.
llvm-svn: 206255
|
|
|
|
|
|
|
|
|
|
| |
Through some oddity where truncate (sextload x) isn't folded into
an anyextload for vectors, the sextload remains if the
vector isn't immediately scalarized. This keeps the expected
zextload instructions in the kernel-args test when small type
vectors aren't scalarized.
llvm-svn: 206070
|
|
|
|
|
|
|
| |
Better match what is done for VOPC to eventually
prefer selecting these.
llvm-svn: 206048
|
|
|
|
|
|
|
| |
This seems generally useful, and makes sense to
go along with SplitVector.
llvm-svn: 206041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also updated as many loops as I could find using df_begin/idf_begin -
strangely I found no uses of idf_begin. Is that just used out of tree?
Also a few places couldn't use df_begin because either they used the
member functions of the depth first iterators or had specific ordering
constraints (I added a comment in the latter case).
Based on a patch by Jim Grosbach. (Jim - you just had iterator_range<T>
where you needed iterator_range<idf_iterator<T>>)
llvm-svn: 206016
|
|
|
|
| |
llvm-svn: 205962
|
|
|
|
| |
llvm-svn: 205961
|
|
|
|
| |
llvm-svn: 205837
|
|
|
|
| |
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
|