summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/AMDGPU/load-lo16.ll
Commit message (Collapse)AuthorAgeFilesLines
* [AMDGPU] Clean up update_llc_test_checks CodeGen testsScott Linder2019-10-241-1/+2
| | | | | | | | | | | | | | Summary: Some tests have been hand edited without removing the update_llc_test_checks header, some have slightly outdated CHECK lines which still pass, and some have additional comments which update_llc_test_checks pushes towards the function body. Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69402
* [AMDGPU] Automatically generate various tests. NFCAmaury Sechet2019-08-231-486/+1551
| | | | llvm-svn: 369787
* [AMDGPU] Created a sub-register class for the return address operand in the ↵Christudasan Devadasan2019-07-091-4/+4
| | | | | | | | | | | | | | return instruction. Function return instruction lowering, currently uses the fixed register pair s[30:31] for holding the return address. It can be any SGPR pair other than the CSRs. Created an SGPR pair sub-register class exclusive of the CSRs, and used this regclass while lowering the return instruction. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D63924 llvm-svn: 365512
* AMDGPU: Always use s33 for global scratch wave offsetMatt Arsenault2019-06-201-12/+12
| | | | | | | | | Every called function could possibly need this to calculate the absolute address of stack objectst, and this avoids inserting a copy around every call site in the kernel. It's also somewhat cleaner to keep this in a callee saved SGPR. llvm-svn: 363990
* AMDGPU: Don't fix emergency stack slot at offset 0Matt Arsenault2019-06-051-10/+10
| | | | | | | | | | | | | | | | | | | | | This forced the caller to be aware of this, which is an ugly ABI feature. Partially reverts r295877. The original reasons for doing this are mostly fixed. Alloca is now in a non-0 address space, so it should be OK to have 0 as a valid pointer. Since we treat the absolute address as the pointer value, this part only really needed to apply to kernels. Since r357093, we avoid the need to increment/decrement the offset register in more cases, and since r354816 the scavenger can fail without spilling, so it's less critical that we try to avoid an offset that fits in the MUBUF offset. Restrict to callable functions for now to split this into 2 steps to limit thte number of test updates and in case anything breaks. llvm-svn: 362665
* AMDGPU: Invert frame index offset interpretationMatt Arsenault2019-06-051-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the beginning, the offset of a frame index has been consistently interpreted backwards. It was treating it as an offset from the scratch wave offset register as a frame register. The correct interpretation is the offset from the SP on entry to the function, before the prolog. Frame index elimination then should select either SP or another register as an FP. Treat the scratch wave offset on kernel entry as the pre-incremented SP. Rely more heavily on the standard hasFP and frame pointer elimination logic, and clean up the private reservation code. This saves a copy in most callee functions. The kernel prolog emission code is still kind of a mess relying on checking the uses of physical registers, which I would prefer to eliminate. Currently selection directly emits MUBUF instructions, which require using a reference to some register. Use the register chosen for SP, and then ignore this later. This should probably be cleaned up to use pseudos that don't refer to any specific base register until frame index elimination. Add a workaround for shaders using large numbers of SGPRs. I'm not sure these cases were ever working correctly, since as far as I can tell the logic for figuring out which SGPR is the scratch wave offset doesn't match up with the shader input initialization in the shader programming guide. llvm-svn: 362661
* AMDGPU: Make sram-ecc off by default for Vega20Konstantin Zhuravlyov2019-03-291-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D59718 llvm-svn: 357247
* AMDGPU: Add more tests for d16 loadsMatt Arsenault2019-03-081-208/+552
| | | | | | Also fix a few cases that weren't testing what they were supposed to. llvm-svn: 355724
* Implement computeKnownBits for scalar_to_vectorStanislav Mekhanoshin2018-11-191-2/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D54728 llvm-svn: 347274
* [AMDGPU] Change constant addr space to 4Yaxun Liu2018-02-131-6/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D43170 llvm-svn: 325030
* [AMDGPU] Switch to the new addr space mapping by defaultYaxun Liu2018-02-021-53/+53
| | | | | | | | This requires corresponding clang change. Differential Revision: https://reviews.llvm.org/D40955 llvm-svn: 324101
* AMDGPU: Don't use MUBUF vaddr if address may overflowMatt Arsenault2017-11-151-24/+24
| | | | | | | Effectively revert r263964. Before we would not allow this if vaddr was not known to be positive. llvm-svn: 318240
* AMDGPU: Fix not converting d16 load/stores to offsetMatt Arsenault2017-11-131-2/+61
| | | | | | Fixes missed optimization with new MUBUF instructions. llvm-svn: 318106
* AMDGPU: Select d16 loads into low component of registerMatt Arsenault2017-11-131-0/+591
llvm-svn: 318005
OpenPOWER on IntegriCloud