summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AMDGPU/FLATInstructions.td
Commit message (Collapse)AuthorAgeFilesLines
...
* AMDGPU: Start adding offset fields to flat instructionsMatt Arsenault2017-06-121-20/+46
| | | | llvm-svn: 305194
* AMDGPU: Remove tfe bit from flat instruction definitionsMatt Arsenault2017-05-111-16/+18
| | | | | | | | | | We don't use it and it was removed in gfx9, and the encoding bit repurposed. Additionally actually using it requires changing the output register class, which wasn't done anyway. llvm-svn: 302814
* [AMDGPU] Get address space mapping by target triple environmentYaxun Liu2017-03-271-6/+6
| | | | | | | | | | | | | | | | | | As we introduced target triple environment amdgiz and amdgizcl, the address space values are no longer enums. We have to decide the value by target triple. The basic idea is to use struct AMDGPUAS to represent address space values. For address space values which are not depend on target triple, use static const members, so that they don't occupy extra memory space and is equivalent to a compile time constant. Since the struct is lightweight and cheap, it can be created on the fly at the point of usage. Or it can be added as member to a pass and created at the beginning of the run* function. Differential Revision: https://reviews.llvm.org/D31284 llvm-svn: 298846
* AMDGPU: split ret/noret patterns for global atomicsJan Vesely2016-12-231-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D27989 llvm-svn: 290435
* AMDGPU: Rename flat operands to match mubufMatt Arsenault2016-11-291-13/+13
| | | | | | | | | | Use vaddr/vdst for the same purposes. This also fixes a beg in SIInsertWaits for the operand check. The stored value operand is currently called data0 in the single offset case, not data. llvm-svn: 288188
* AMDGPU: Add VI i16 supportTom Stellard2016-11-101-0/+6
| | | | | | | | Patch By: Wei Ding Differential Revision: https://reviews.llvm.org/D18049 llvm-svn: 286464
* Revert "AMDGPU: Add VI i16 support"Tom Stellard2016-11-041-6/+0
| | | | | | This reverts commit r285939 and r285948. These broke some conformance tests. llvm-svn: 285995
* AMDGPU: Add VI i16 supportTom Stellard2016-11-031-0/+6
| | | | | | | | Patch By: Wei Ding Differential Revision: https://reviews.llvm.org/D18049 llvm-svn: 285939
* AMDGPU: Rename glc operand typeMatt Arsenault2016-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | While trying to add the glc bit to SMEM instructions on VI with the new refactoring I ran into some kind of shadowing problem for the glc operand when using the pseudoinstruction as a multiclass parameter. Everywhere that currently uses it defines the operand to have the same name as its type, i.e. glc:$glc which works. For some reason now it conflicts, and its up evaluating to the wrong thing. For the real encoding classes, let Inst{16} = !if(ps.has_glc, glc, ?); was not being evaluated and still visible in the Inst initializer in the expanded td file. In other cases I got a a different error about an illegal operand where this was using { 0 } initializer from the bits<1> glc initializer instead of evaluating it as false in the if. For consistency all of the operand types should probably be captialized to avoid conflicting with the variable names unless somebody has a better idea of how to fix this. llvm-svn: 285462
* [AMDGPU] Refactor FLAT TD instructionsValery Pykhtin2016-09-051-0/+524
Differential revision: https://reviews.llvm.org/D24072 llvm-svn: 280655
OpenPOWER on IntegriCloud