summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/LoopStrengthReduce/AMDGPU
Commit message (Collapse)AuthorAgeFilesLines
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-241-1/+1
| | | | as cleanups after D56351
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-171-1/+0
| | | | llvm-svn: 363538
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-177-0/+619
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-177-619/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* AMDGPU: Fix some outdated datalayouts in testsMatt Arsenault2018-09-134-4/+4
| | | | llvm-svn: 342131
* reapply r334209 with fixes for harfbuzz in ChromiumDaniil Fukalov2018-06-081-1/+42
| | | | | | | | | | | r334209 description: [LSR] Check yet more intrinsic pointer operands the patch fixes another assertion in isLegalUse() Differential Revision: https://reviews.llvm.org/D47794 llvm-svn: 334300
* Revert r334209 "[LSR] Check yet more intrinsic pointer operands"Reid Kleckner2018-06-081-42/+1
| | | | | | | This causes cast failures when compiling harfbuzz in Chromium. Reproducer on the way. llvm-svn: 334254
* [LSR] Check yet more intrinsic pointer operandsDaniil Fukalov2018-06-071-1/+42
| | | | | | | | the patch fixes another assertion in isLegalUse() Differential Revision: https://reviews.llvm.org/D47794 llvm-svn: 334209
* [AMDGPU] Move lsr test. NFC.Stanislav Mekhanoshin2018-05-171-0/+37
| | | | llvm-svn: 332562
* [AMDGPU] Switch to the new addr space mapping by defaultYaxun Liu2018-02-021-3/+2
| | | | | | | | This requires corresponding clang change. Differential Revision: https://reviews.llvm.org/D40955 llvm-svn: 324101
* LSR: Check more intrinsic pointer operandsMatt Arsenault2017-12-111-1/+81
| | | | llvm-svn: 320424
* AMDGPU: Mark all unspecified CC functions in tests as amdgpu_kernelMatt Arsenault2017-03-215-12/+12
| | | | | | | | | | | | Currently the default C calling convention functions are treated the same as compute kernels. Make this explicit so the default calling convention can be changed to a non-kernel. Converted with perl -pi -e 's/define void/define amdgpu_kernel void/' on the relevant test directories (and undoing in one place that actually wanted a non-kernel). llvm-svn: 298444
* [LSR] Pointers with different address spaces are considered incompatible.Mikael Holmen2017-02-141-0/+31
| | | | | | | | | | | | | | | | | | | | | | Summary: Function isCompatibleIVType is already used as a guard before the call to SE.getMinusSCEV(OperExpr, PrevExpr); in LSRInstance::ChainInstruction. getMinusSCEV requires the expressions to be of the same type, so we now consider two pointers with different address spaces to be incompatible, since it is possible that the pointers in fact have different sizes. Reviewers: qcolombet, eli.friedman Reviewed By: qcolombet Subscribers: nhaehnle, Ka-Ka, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D29885 llvm-svn: 295033
* LSR: Check atomic instruction pointer operandsMatt Arsenault2017-02-081-0/+87
| | | | llvm-svn: 294410
* LSR: Don't drop address space when type doesn't matchMatt Arsenault2017-01-301-0/+54
| | | | | | | | | | For targets with different addressing modes in each address space, if this is dropped querying isLegalAddressingMode later with this will give a nonsense result, breaking the isLegalUse assertions. This is a candidate for the 4.0 release branch. llvm-svn: 293542
* AMDGPU: Run pointer optimization passesMatt Arsenault2016-06-151-1/+2
| | | | llvm-svn: 272736
* AMDGPU: Fix a few slightly broken testsMatt Arsenault2016-05-181-22/+23
| | | | | | | Fix minor bugs and uses of undef which break when pointer related optimization passes are run. llvm-svn: 269944
* AMDGPU: Stop reporting an addressing mode for unknown addrspaceMatt Arsenault2016-04-291-4/+20
| | | | | | | | | This was being treated the same as private, which has an immediate offset. For unknown, it probably means it's for a computation not actually being used for accessing memory, so it should not have a nontrivial addressing mode. llvm-svn: 268002
* LoopStrengthReduce: Try to pass address space to isLegalAddressingModeMatt Arsenault2015-08-153-0/+272
This seems to only work some of the time. In some situations, this seems to use a nonsensical type and isn't actually aware of the memory being accessed. e.g. if branch condition is an icmp of a pointer, it checks the addressing mode of i1. llvm-svn: 245137
OpenPOWER on IntegriCloud