| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The type of the immediates should not matter as long as the encoding is
equivalent to the encoding of one of the legal inline constants.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 204056
|
|
|
|
|
|
|
|
|
|
|
|
| |
This instructions writes to an 32-bit SGPR. This change required adding
the 32-bit VCC_LO and VCC_HI registers, because the full VCC register
is 64 bits.
This fixes verifier errors on several of the indirect addressing piglit
tests.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 204055
|
|
|
|
|
|
|
| |
Added checks for number of operands and operand register classes.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 204054
|
|
|
|
|
|
| |
Private pointers are now always 32-bits.
llvm-svn: 203989
|
|
|
|
|
|
|
| |
Use sign_extend_inreg and getZeroExtendInReg instead of
using the bit operations they expand into.
llvm-svn: 203988
|
|
|
|
|
|
|
|
|
|
| |
operator* on the by-operand iterators to return a MachineOperand& rather than
a MachineInstr&. At this point they almost behave like normal iterators!
Again, this requires making some existing loops more verbose, but should pave
the way for the big range-based for-loop cleanups in the future.
llvm-svn: 203865
|
|
|
|
|
|
|
|
|
| |
LDS instructions are pseudo instructions which model
the OQAP defs and uses within a single instruction.
This fixes a hang in the opencv MedianFilter tests.
llvm-svn: 203818
|
|
|
|
| |
llvm-svn: 203695
|
|
|
|
| |
llvm-svn: 203527
|
|
|
|
| |
llvm-svn: 203518
|
|
|
|
| |
llvm-svn: 203517
|
|
|
|
| |
llvm-svn: 203516
|
|
|
|
| |
llvm-svn: 203515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the stack of the analysis group because they are all immutable passes.
This is made clear by Craig's recent work to use override
systematically -- we weren't overriding anything for 'finalizePass'
because there is no such thing.
This is kind of a lame restriction on the API -- we can no longer push
and pop things, we just set up the stack and run. However, I'm not
invested in building some better solution on top of the existing
(terrifying) immutable pass and legacy pass manager.
llvm-svn: 203437
|
|
|
|
|
| |
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 203281
|
|
|
|
|
|
|
|
| |
These are sometimes created by the shrink to boolean optimization in the
globalopt pass.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 203280
|
|
|
|
|
|
|
| |
This appears to only be working for global loads. Private
and local break for other reasons.
llvm-svn: 203135
|
|
|
|
| |
llvm-svn: 203134
|
|
|
|
| |
llvm-svn: 203133
|
|
|
|
|
|
| |
obviously coupled to the IR.
llvm-svn: 203064
|
|
|
|
| |
llvm-svn: 203013
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
llvm-svn: 202824
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
| |
llvm-svn: 202621
|
|
|
|
| |
llvm-svn: 202618
|
|
|
|
|
|
|
| |
Make a call to R600's implementation of verifyInstruction() to
check that instructions are only using legal operands.
llvm-svn: 202544
|
|
|
|
| |
llvm-svn: 202543
|
|
|
|
|
|
|
| |
We moved MCJIT to use native object formats a long time ago and R600
now uses ELF, so it was dead.
llvm-svn: 202408
|
|
|
|
|
|
|
|
| |
If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 202337
|
|
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 202336
|
|
|
|
|
|
| |
It is already fully handled in AMDGPUISelDAGToDAG.
llvm-svn: 202312
|
|
|
|
|
|
|
| |
This causes the size of the scrypt kernel to explode and eats all the
memory on some systems.
llvm-svn: 202195
|