<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/CodeGen/AMDGPU/llvm.amdgcn.struct.buffer.atomic.ll, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>AMDGPU: Replace &lt;4 x i32&gt; undef uses in tests with poison (#130902)</title>
<updated>2025-03-13T01:28:48+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2025-03-13T01:28:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c182f4042adae606a6312cc63e305a9fad5fd603'/>
<id>c182f4042adae606a6312cc63e305a9fad5fd603</id>
<content type='text'>
Most of these are from resource descriptors.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most of these are from resource descriptors.</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU,test] Change llc -march= to -mtriple= (#75982)</title>
<updated>2024-01-17T05:54:58+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2024-01-17T05:54:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9e9907f1cfa424366fba58d9520f9305b537cec9'/>
<id>9e9907f1cfa424366fba58d9520f9305b537cec9</id>
<content type='text'>
Similar to 806761a7629df268c8aed49657aeccffa6bca449.

For IR files without a target triple, -mtriple= specifies the full
target triple while -march= merely sets the architecture part of the
default target triple, leaving a target triple which may not make sense,
e.g. amdgpu-apple-darwin.

Therefore, -march= is error-prone and not recommended for tests without
a target triple. The issue has been benign as we recognize
$unknown-apple-darwin as ELF instead of rejecting it outrightly.

This patch changes AMDGPU tests to not rely on the default
OS/environment components. Tests that need fixes are not changed:

```
  LLVM :: CodeGen/AMDGPU/fabs.f64.ll
  LLVM :: CodeGen/AMDGPU/fabs.ll
  LLVM :: CodeGen/AMDGPU/floor.ll
  LLVM :: CodeGen/AMDGPU/fneg-fabs.f64.ll
  LLVM :: CodeGen/AMDGPU/fneg-fabs.ll
  LLVM :: CodeGen/AMDGPU/r600-infinite-loop-bug-while-reorganizing-vector.ll
  LLVM :: CodeGen/AMDGPU/schedule-if-2.ll
```</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similar to 806761a7629df268c8aed49657aeccffa6bca449.

For IR files without a target triple, -mtriple= specifies the full
target triple while -march= merely sets the architecture part of the
default target triple, leaving a target triple which may not make sense,
e.g. amdgpu-apple-darwin.

Therefore, -march= is error-prone and not recommended for tests without
a target triple. The issue has been benign as we recognize
$unknown-apple-darwin as ELF instead of rejecting it outrightly.

This patch changes AMDGPU tests to not rely on the default
OS/environment components. Tests that need fixes are not changed:

```
  LLVM :: CodeGen/AMDGPU/fabs.f64.ll
  LLVM :: CodeGen/AMDGPU/fabs.ll
  LLVM :: CodeGen/AMDGPU/floor.ll
  LLVM :: CodeGen/AMDGPU/fneg-fabs.f64.ll
  LLVM :: CodeGen/AMDGPU/fneg-fabs.ll
  LLVM :: CodeGen/AMDGPU/r600-infinite-loop-bug-while-reorganizing-vector.ll
  LLVM :: CodeGen/AMDGPU/schedule-if-2.ll
```</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] CodeGen for 64-bit buffer atomic cmpswap intrinsics (#70475)</title>
<updated>2023-10-30T16:44:22+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2023-10-30T16:44:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=101008be830bb475f717a388c69cea1f48677baf'/>
<id>101008be830bb475f717a388c69cea1f48677baf</id>
<content type='text'>
Implement codegen for:
llvm.amdgcn.raw.buffer.atomic.cmpswap.i64
llvm.amdgcn.raw.ptr.buffer.atomic.cmpswap.i64
llvm.amdgcn.struct.buffer.atomic.cmpswap.i64
llvm.amdgcn.struct.ptr.buffer.atomic.cmpswap.i64</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implement codegen for:
llvm.amdgcn.raw.buffer.atomic.cmpswap.i64
llvm.amdgcn.raw.ptr.buffer.atomic.cmpswap.i64
llvm.amdgcn.struct.buffer.atomic.cmpswap.i64
llvm.amdgcn.struct.ptr.buffer.atomic.cmpswap.i64</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Switch to the new cl option amdgpu-atomic-optimizer-strategy.</title>
<updated>2023-06-22T11:06:42+00:00</updated>
<author>
<name>Pravin Jagtap</name>
<email>Pravin.Jagtap@amd.com</email>
</author>
<published>2023-06-22T11:03:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=597fb7fb4640a85c7e144c1ee2b2d0d5e1da4c84'/>
<id>597fb7fb4640a85c7e144c1ee2b2d0d5e1da4c84</id>
<content type='text'>
Atomic optimizer is turned on by default through D152649. This patch
removes the usage of old command line option amdgpu-atomic-optimizations
and transfer the responsibility to `amdgpu-atomic-optimizer-strategy`.

We can safely remove old option when LLPC remove its all usage.

Reviewed By: foad, arsenm, #amdgpu, cdevadas

Differential Revision: https://reviews.llvm.org/D153007
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Atomic optimizer is turned on by default through D152649. This patch
removes the usage of old command line option amdgpu-atomic-optimizations
and transfer the responsibility to `amdgpu-atomic-optimizer-strategy`.

We can safely remove old option when LLPC remove its all usage.

Reviewed By: foad, arsenm, #amdgpu, cdevadas

Differential Revision: https://reviews.llvm.org/D153007
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Removed unused prefixes from CodeGen/AMDGPU</title>
<updated>2021-01-06T17:34:11+00:00</updated>
<author>
<name>Mircea Trofin</name>
<email>mtrofin@google.com</email>
</author>
<published>2021-01-06T04:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b47063091304410e77cf2e03913d9f093b3ef60d'/>
<id>b47063091304410e77cf2e03913d9f093b3ef60d</id>
<content type='text'>
All the 'l'-starting tests.

Differential Revision: https://reviews.llvm.org/D94151
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the 'l'-starting tests.

Differential Revision: https://reviews.llvm.org/D94151
</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] add buffer_atomic_swap for float</title>
<updated>2020-08-06T01:45:48+00:00</updated>
<author>
<name>Ruiling Song</name>
<email>ruiling.song@amd.com</email>
</author>
<published>2020-08-04T01:54:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5ddc8b49babbbad8b00de6bd410b77c9ade8b325'/>
<id>5ddc8b49babbbad8b00de6bd410b77c9ade8b325</id>
<content type='text'>
The functionality is used when calling imageAtomicExhange() on float
type imageBuffer in Graphics shaders.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D85187
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The functionality is used when calling imageAtomicExhange() on float
type imageBuffer in Graphics shaders.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D85187
</pre>
</div>
</content>
</entry>
<entry>
<title>[MachineScheduler] Fix the TopDepth/BotHeightReduce latency heuristics</title>
<updated>2020-07-17T10:02:13+00:00</updated>
<author>
<name>Jay Foad</name>
<email>jay.foad@amd.com</email>
</author>
<published>2020-01-07T15:43:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=62fd7f767c4151b4ec3f4f703e73a27c52f5315c'/>
<id>62fd7f767c4151b4ec3f4f703e73a27c52f5315c</id>
<content type='text'>
tryLatency compares two sched candidates. For the top zone it prefers
the one with lesser depth, but only if that depth is greater than the
total latency of the instructions we've already scheduled -- otherwise
its latency would be hidden and there would be no stall.

Unfortunately it only tests the depth of one of the candidates. This can
lead to situations where the TopDepthReduce heuristic does not kick in,
but a lower priority heuristic chooses the other candidate, whose depth
*is* greater than the already scheduled latency, which causes a stall.

The fix is to apply the heuristic if the depth of *either* candidate is
greater than the already scheduled latency.

All this also applies to the BotHeightReduce heuristic in the bottom
zone.

Differential Revision: https://reviews.llvm.org/D72392
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tryLatency compares two sched candidates. For the top zone it prefers
the one with lesser depth, but only if that depth is greater than the
total latency of the instructions we've already scheduled -- otherwise
its latency would be hidden and there would be no stall.

Unfortunately it only tests the depth of one of the candidates. This can
lead to situations where the TopDepthReduce heuristic does not kick in,
but a lower priority heuristic chooses the other candidate, whose depth
*is* greater than the already scheduled latency, which causes a stall.

The fix is to apply the heuristic if the depth of *either* candidate is
greater than the already scheduled latency.

All this also applies to the BotHeightReduce heuristic in the bottom
zone.

Differential Revision: https://reviews.llvm.org/D72392
</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: add missing llvm.amdgcn.{raw,struct}.buffer.atomic.{inc,dec}</title>
<updated>2019-08-05T09:36:06+00:00</updated>
<author>
<name>Nicolai Haehnle</name>
<email>nhaehnle@gmail.com</email>
</author>
<published>2019-08-05T09:36:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e204786b6cc968bfe725b21241c00228d1159e75'/>
<id>e204786b6cc968bfe725b21241c00228d1159e75</id>
<content type='text'>
Summary:
Wrapping increment/decrement. These aren't exposed by many APIs...

Change-Id: I1df25c7889de5a5ba76468ad8e8a2597efa9af6c

Reviewers: arsenm, tpr, dstuttard

Subscribers: kzhuravl, jvesely, wdng, yaxunl, t-tye, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 367821
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
Wrapping increment/decrement. These aren't exposed by many APIs...

Change-Id: I1df25c7889de5a5ba76468ad8e8a2597efa9af6c

Reviewers: arsenm, tpr, dstuttard

Subscribers: kzhuravl, jvesely, wdng, yaxunl, t-tye, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 367821
</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: Future-proof {raw,struct}.buffer.atomic intrinsics</title>
<updated>2018-10-08T16:53:48+00:00</updated>
<author>
<name>Nicolai Haehnle</name>
<email>nhaehnle@gmail.com</email>
</author>
<published>2018-10-08T16:53:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ea36cd595c8fb82f58c72c3db9ff0fdda8959fe2'/>
<id>ea36cd595c8fb82f58c72c3db9ff0fdda8959fe2</id>
<content type='text'>
Summary:
The ISA is really supposed to support 64-bit atomics as well,
so the data type should be an overload.

Mesa doesn't use these atomics yet, in fact I noticed this
issue while trying to use the atomics from Mesa.

Change-Id: I77f58317a085a0d3eb933cc7e99308c48a19f83e

Reviewers: tpr

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, t-tye, jfb, llvm-commits

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

llvm-svn: 343978
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
The ISA is really supposed to support 64-bit atomics as well,
so the data type should be an overload.

Mesa doesn't use these atomics yet, in fact I noticed this
issue while trying to use the atomics from Mesa.

Change-Id: I77f58317a085a0d3eb933cc7e99308c48a19f83e

Reviewers: tpr

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, t-tye, jfb, llvm-commits

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

llvm-svn: 343978
</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Add an AMDGPU specific atomic optimizer.</title>
<updated>2018-10-08T15:49:19+00:00</updated>
<author>
<name>Neil Henning</name>
<email>neil.henning@amd.com</email>
</author>
<published>2018-10-08T15:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6641657453170b57d05de8aea095b0f41f7ba4fe'/>
<id>6641657453170b57d05de8aea095b0f41f7ba4fe</id>
<content type='text'>
This commit adds a new IR level pass to the AMDGPU backend to perform
atomic optimizations. It works by:

- Running through a function and finding atomicrmw add/sub or uses of
  the atomic buffer intrinsics for add/sub.
- If all arguments except the value to be added/subtracted are uniform,
  record the value to be optimized.
- Run through the atomic operations we can optimize and, depending on
  whether the value is uniform/divergent use wavefront wide operations
  (DPP in the divergent case) to calculate the total amount to be
  atomically added/subtracted.
- Then let only a single lane of each wavefront perform the atomic
  operation, reducing the total number of atomic operations in flight.
- Lastly we recombine the result from the single lane to each lane of
  the wavefront, and calculate our individual lanes offset into the
  final result.

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

llvm-svn: 343973
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit adds a new IR level pass to the AMDGPU backend to perform
atomic optimizations. It works by:

- Running through a function and finding atomicrmw add/sub or uses of
  the atomic buffer intrinsics for add/sub.
- If all arguments except the value to be added/subtracted are uniform,
  record the value to be optimized.
- Run through the atomic operations we can optimize and, depending on
  whether the value is uniform/divergent use wavefront wide operations
  (DPP in the divergent case) to calculate the total amount to be
  atomically added/subtracted.
- Then let only a single lane of each wavefront perform the atomic
  operation, reducing the total number of atomic operations in flight.
- Lastly we recombine the result from the single lane to each lane of
  the wavefront, and calculate our individual lanes offset into the
  final result.

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

llvm-svn: 343973
</pre>
</div>
</content>
</entry>
</feed>
