llvm-project.git/llvm/test/CodeGen/AMDGPU/add3.ll, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. AMDGPU: Replace insertelement poison with insertelement undef (#130896) 2025-03-12T13:33:33+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2025-03-12T13:33:33+00:00 da42b2f67da603d19be4ab0ee33ae79e20c12c6c This is the bulk update with perl, with cases which require additional update left for later. 
This is the bulk update with perl, with cases which require additional
update left for later.
 [AMDGPU] Introduce SIInstrWorklist to process instructions in moveToVALU 2023-04-10T06:04:14+00:00 skc7 Krishna.Sankisa@amd.com 2023-03-28T18:05:02+00:00 b434051dc83d77c8e8e349ab1992dcb0c795a7ea Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D147168 
Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D147168
[AMDGPU] Lowering VGPR to SGPR copies to v_readfirstlane_b32 if profitable. 2022-07-14T21:59:02+00:00 Alexander Timofeev alexander.timofeev@amd.com 2022-06-21T08:57:58+00:00 2e29b0138ca243c7d288622524a004c84acbbb9e Since the divergence-driven instruction selection has been enabled for AMDGPU, all the uniform instructions are expected to be selected to SALU form, except those not having one. VGPR to SGPR copies appear in MIR to connect values producers and consumers. This change implements an algorithm that evolves a reasonable tradeoff between the profit achieved from keeping the uniform instructions in SALU form and overhead introduced by the data transfer between the VGPRs and SGPRs. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D128252 
Since the divergence-driven instruction selection has been enabled for AMDGPU,
 all the uniform instructions are expected to be selected to SALU form, except those not having one.
 VGPR to SGPR copies appear in MIR to connect values producers and consumers. This change implements an algorithm
 that evolves a reasonable tradeoff between the profit achieved from keeping the uniform instructions in SALU form
 and overhead introduced by the data transfer between the VGPRs and SGPRs.

Reviewed By: rampitec

Differential Revision: https://reviews.llvm.org/D128252
[AMDGPU] Add GFX11 test coverage 2022-07-08T08:13:59+00:00 Jay Foad jay.foad@amd.com 2022-07-06T11:14:57+00:00 5cae88164e5247d01f6a814cf610fa667c9aa9a6 Add GFX11 test coverage to a bunch of tests where it was easy to do so, mostly because the checks are autogenerated and/or GFX11 can share the same checks as GFX10. Differential Revision: https://reviews.llvm.org/D129295 
Add GFX11 test coverage to a bunch of tests where it was easy to do so,
mostly because the checks are autogenerated and/or GFX11 can share the
same checks as GFX10.

Differential Revision: https://reviews.llvm.org/D129295
[AMDGPU] Switch PostRA sched to MachineSched 2021-09-14T19:11:27+00:00 Joe Nash Joseph.Nash@amd.com 2021-09-08T17:22:15+00:00 3ce1b9631a50d4853ab6d5750eaf50951b49e89d Use GCNHazardRecognizer in postra sched. Updated tests for the new schedules. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D109536 Change-Id: Ia86ba2ae168f12fb34b4d8efdab491f84d936cde 
Use GCNHazardRecognizer in postra sched.
Updated tests for the new schedules.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D109536

Change-Id: Ia86ba2ae168f12fb34b4d8efdab491f84d936cde
[AMDGPU] Stop adding an implicit def of vcc_hi for wave32 2020-12-02T10:11:42+00:00 Jay Foad jay.foad@amd.com 2020-12-01T11:55:50+00:00 d28624a209484c440290472dadc2673c8a0b47e7 This doesn't seem to be needed for anything. Differential Revision: https://reviews.llvm.org/D92400 
This doesn't seem to be needed for anything.

Differential Revision: https://reviews.llvm.org/D92400
[AMDGPU] Remove dubious logic in bidirectional list scheduler 2020-02-28T21:35:34+00:00 Jay Foad jay.foad@amd.com 2019-10-07T14:33:59+00:00 43830790d76baf8a2488ae7c8179ec347ce43e8c Summary: pickNodeBidirectional tried to compare the best top candidate and the best bottom candidate by examining TopCand.Reason and BotCand.Reason. This is unsound because, after calling pickNodeFromQueue, Cand.Reason does not reflect the most important reason why Cand was chosen. Rather it reflects the most recent reason why it beat some other potential candidate, which could have been for some low priority tie breaker reason. I have seen this cause problems where TopCand is a good candidate, but because TopCand.Reason is ORDER (which is very low priority) it is repeatedly ignored in favour of a mediocre BotCand. This is not how bidirectional scheduling is supposed to work. To fix this I changed the code to always compare TopCand and BotCand directly, like the generic implementation of pickNodeBidirectional does. This removes some uncommented AMDGPU-specific logic; if this logic turns out to be important then perhaps it could be moved into an override of tryCandidate instead. Graphics shader benchmarking on gfx10 shows a lot more positive than negative effects from this change. Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68338 
Summary:
pickNodeBidirectional tried to compare the best top candidate and the
best bottom candidate by examining TopCand.Reason and BotCand.Reason.
This is unsound because, after calling pickNodeFromQueue, Cand.Reason
does not reflect the most important reason why Cand was chosen. Rather
it reflects the most recent reason why it beat some other potential
candidate, which could have been for some low priority tie breaker
reason.

I have seen this cause problems where TopCand is a good candidate, but
because TopCand.Reason is ORDER (which is very low priority) it is
repeatedly ignored in favour of a mediocre BotCand. This is not how
bidirectional scheduling is supposed to work.

To fix this I changed the code to always compare TopCand and BotCand
directly, like the generic implementation of pickNodeBidirectional does.
This removes some uncommented AMDGPU-specific logic; if this logic turns
out to be important then perhaps it could be moved into an override of
tryCandidate instead.

Graphics shader benchmarking on gfx10 shows a lot more positive than
negative effects from this change.

Reviewers: arsenm, tstellar, rampitec, kzhuravl, vpykhtin, dstuttard, tpr, atrick, MatzeB

Subscribers: jvesely, wdng, nhaehnle, yaxunl, t-tye, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68338
[AMDGPU] gfx1010 core wave32 changes 2019-06-20T15:08:34+00:00 Stanislav Mekhanoshin Stanislav.Mekhanoshin@amd.com 2019-06-20T15:08:34+00:00 0846c125f98ba6e1013b5acd1b161bd32b395bf8 Differential Revision: https://reviews.llvm.org/D63204 llvm-svn: 363934 
Differential Revision: https://reviews.llvm.org/D63204

llvm-svn: 363934
[AMDGPU] Pattern for v_xor3_b32 2019-05-10T00:09:01+00:00 Stanislav Mekhanoshin Stanislav.Mekhanoshin@amd.com 2019-05-10T00:09:01+00:00 64196850f0e9b31d1c3bbfcb52ab76d9901f42ef This also allows three op patterns to use increased constant bus limit of GFX10. Differential Revision: https://reviews.llvm.org/D61763 llvm-svn: 360395 
This also allows three op patterns to use increased constant bus
limit of GFX10.

Differential Revision: https://reviews.llvm.org/D61763

llvm-svn: 360395
[AMDGPU] gfx1010: prefer V_MUL_LO_U32 over V_MUL_LO_I32 2019-05-06T22:27:05+00:00 Stanislav Mekhanoshin Stanislav.Mekhanoshin@amd.com 2019-05-06T22:27:05+00:00 971cb8b633b02237ef981691e80d91f2f8a2bce5 GFX10 deprecates v_mul_lo_i32 instruction, so choose u32 form for all targets. Differential Revision: https://reviews.llvm.org/D61525 llvm-svn: 360094 
GFX10 deprecates v_mul_lo_i32 instruction, so choose u32 form for
all targets.

Differential Revision: https://reviews.llvm.org/D61525

llvm-svn: 360094