<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/CodeGen/AMDGPU/min.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] Do not promote uniform i16 operations to i32 in CGP (#140208)</title>
<updated>2025-05-16T08:31:03+00:00</updated>
<author>
<name>Pierre van Houtryve</name>
<email>pierre.vanhoutryve@amd.com</email>
</author>
<published>2025-05-16T08:31:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aacebaeab5448b4ef614aa8aca52ca210e451f79'/>
<id>aacebaeab5448b4ef614aa8aca52ca210e451f79</id>
<content type='text'>
For the majority of cases, this is a neutral or positive change.
There are even testcases that greatly benefit from it, but some regressions are possible.
There is #140040 for GlobalISel that'd need to be fixed but it's only a one instruction regression and I think it can be fixed later.

Solves #64591</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For the majority of cases, this is a neutral or positive change.
There are even testcases that greatly benefit from it, but some regressions are possible.
There is #140040 for GlobalISel that'd need to be fixed but it's only a one instruction regression and I think it can be fixed later.

Solves #64591</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Handle min/max in isNarrowingProfitable (#140206)</title>
<updated>2025-05-16T08:16:44+00:00</updated>
<author>
<name>Pierre van Houtryve</name>
<email>pierre.vanhoutryve@amd.com</email>
</author>
<published>2025-05-16T08:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fd85ffb4c43be80c179145a382d78a7c9ca3c1b7'/>
<id>fd85ffb4c43be80c179145a382d78a7c9ca3c1b7</id>
<content type='text'>
Introduces a slight regression in some cases but it'll even out once we
disable the promotion in CGP.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduces a slight regression in some cases but it'll even out once we
disable the promotion in CGP.</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU][True16][CodeGen] update GFX11Plus codegen test with true16 flag (#135078)</title>
<updated>2025-04-23T17:06:52+00:00</updated>
<author>
<name>Brox Chen</name>
<email>guochen2@amd.com</email>
</author>
<published>2025-04-23T17:06:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6dbc01e8015816e904687c03f0ea8afac817781d'/>
<id>6dbc01e8015816e904687c03f0ea8afac817781d</id>
<content type='text'>
This is a NFC patch.

This patch run a bulk update on CodeGen tests that are impacted by the
true16 features. This patch applies:
1. duplicate GFX11plus runlines and apply them with
"+mattr=+real-true16" and "+mattr=-real-true16"
2. update the test with the update script

For some GISEL runlines, the current CodeGen do not fully support the
true16 version. Still update the runlines, but comment out the failing
one, and added a "FIXME-TRUE16" comment to that test for easier
tracking. These test will be fixed in the following patches.

This is in a transition state that we support both
"+real-true16/-real-true16" in our code base. We plan to move to
"+real-true16" as default, and finally remove "-real-true16" mode and
test lines.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a NFC patch.

This patch run a bulk update on CodeGen tests that are impacted by the
true16 features. This patch applies:
1. duplicate GFX11plus runlines and apply them with
"+mattr=+real-true16" and "+mattr=-real-true16"
2. update the test with the update script

For some GISEL runlines, the current CodeGen do not fully support the
true16 version. Still update the runlines, but comment out the failing
one, and added a "FIXME-TRUE16" comment to that test for easier
tracking. These test will be fixed in the following patches.

This is in a transition state that we support both
"+real-true16/-real-true16" in our code base. We plan to move to
"+real-true16" as default, and finally remove "-real-true16" mode and
test lines.</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Remove the AnnotateKernelFeatures pass (#130198)</title>
<updated>2025-04-15T22:17:33+00:00</updated>
<author>
<name>Jun Wang</name>
<email>jwang86@yahoo.com</email>
</author>
<published>2025-04-15T22:17:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=31f39c83259401a26b3660dd75f645002258571d'/>
<id>31f39c83259401a26b3660dd75f645002258571d</id>
<content type='text'>
Previously the AnnotateKernelFeatures pass infers two attributes:
amdgpu-calls and amdgpu-stack-objects, which are used to help determine
if flat scratch init is allowed. PR #118907 created the
amdgpu-no-flat-scratch-init attribute. Continuing with that work, this
patch makes use of this attribute to determine flat scratch init,
replacing amdgpu-calls and amdgpu-stack-objects. This also leads to the
removal of the AnnotateKernelFeatures pass.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously the AnnotateKernelFeatures pass infers two attributes:
amdgpu-calls and amdgpu-stack-objects, which are used to help determine
if flat scratch init is allowed. PR #118907 created the
amdgpu-no-flat-scratch-init attribute. Continuing with that work, this
patch makes use of this attribute to determine flat scratch init,
replacing amdgpu-calls and amdgpu-stack-objects. This also leads to the
removal of the AnnotateKernelFeatures pass.</pre>
</div>
</content>
</entry>
<entry>
<title>Reland "[AMDGPU] Remove s_delay_alu for VALU-&gt;SGPR-&gt;SALU (#127212)" (#131111)</title>
<updated>2025-03-13T09:26:20+00:00</updated>
<author>
<name>Ana Mihajlovic</name>
<email>Ana.Mihajlovic@amd.com</email>
</author>
<published>2025-03-13T09:26:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=459b4e3fe10805b110bc89aa857532715bfe54e0'/>
<id>459b4e3fe10805b110bc89aa857532715bfe54e0</id>
<content type='text'>
We have a VALU-&gt;SGPR-&gt;SALU (VALU writing to SGPR and SALU reading from
it). When VALU is issued, it increments internal counter VA_SDST used to
track use of this SGPR. SALU will not issue until VA_SDST is zero, that
is when VALU is finished writing. Therefore, delays added by s_delay_alu
are not needed in this situation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have a VALU-&gt;SGPR-&gt;SALU (VALU writing to SGPR and SALU reading from
it). When VALU is issued, it increments internal counter VA_SDST used to
track use of this SGPR. SALU will not issue until VA_SDST is zero, that
is when VALU is finished writing. Therefore, delays added by s_delay_alu
are not needed in this situation.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[AMDGPU] Remove s_delay_alu for VALU-&gt;SGPR-&gt;SALU (#127212)"</title>
<updated>2025-03-12T19:09:09+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-03-12T19:09:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aa008e00085a260b2ed130b3430cc4640144ab30'/>
<id>aa008e00085a260b2ed130b3430cc4640144ab30</id>
<content type='text'>
This reverts commit 71582c6667a6334c688734cae628e906b3c1ac1d.

Multiple buildbot failures have been reported:
https://github.com/llvm/llvm-project/pull/127212
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 71582c6667a6334c688734cae628e906b3c1ac1d.

Multiple buildbot failures have been reported:
https://github.com/llvm/llvm-project/pull/127212
</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Remove s_delay_alu for VALU-&gt;SGPR-&gt;SALU (#127212)</title>
<updated>2025-03-12T16:33:07+00:00</updated>
<author>
<name>Ana Mihajlovic</name>
<email>Ana.Mihajlovic@amd.com</email>
</author>
<published>2025-03-12T16:33:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=71582c6667a6334c688734cae628e906b3c1ac1d'/>
<id>71582c6667a6334c688734cae628e906b3c1ac1d</id>
<content type='text'>
We have a VALU-&gt;SGPR-&gt;SALU (VALU writing to SGPR and SALU reading from
it). When VALU is issued, it increments internal counter VA_SDST used to
track use of this SGPR. SALU will not issue until VA_SDST is zero, that
is when VALU is finished writing. Therefore, delays added by s_delay_alu
are not needed in this situation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have a VALU-&gt;SGPR-&gt;SALU (VALU writing to SGPR and SALU reading from
it). When VALU is issued, it increments internal counter VA_SDST used to
track use of this SGPR. SALU will not issue until VA_SDST is zero, that
is when VALU is finished writing. Therefore, delays added by s_delay_alu
are not needed in this situation.</pre>
</div>
</content>
</entry>
<entry>
<title>DAG: Avoid stack usage in bitcast operand promotion to legal vector (#125637)</title>
<updated>2025-02-04T09:43:42+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2025-02-04T09:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2f2ac3de69dde902c9fe84bdd7faeee320498130'/>
<id>2f2ac3de69dde902c9fe84bdd7faeee320498130</id>
<content type='text'>
Fix introducing stack usage if a bitcast source operand is an illegal
integer type cast to a legal vector type. This should cover more
situations, but this is the first one I noticed.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix introducing stack usage if a bitcast source operand is an illegal
integer type cast to a legal vector type. This should cover more
situations, but this is the first one I noticed.</pre>
</div>
</content>
</entry>
<entry>
<title>Reapply "[AMDGPU] Still set up the two SGPRs for queue ptr even it is COV5 (#112403)"</title>
<updated>2024-11-09T01:21:16+00:00</updated>
<author>
<name>Shilei Tian</name>
<email>i@tianshilei.me</email>
</author>
<published>2024-11-09T01:21:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6548b6354d1d990e1c98736f5e7c3de876bedc8e'/>
<id>6548b6354d1d990e1c98736f5e7c3de876bedc8e</id>
<content type='text'>
This reverts commit ca33649abe5fad93c57afef54e43ed9b3249cd86.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit ca33649abe5fad93c57afef54e43ed9b3249cd86.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[AMDGPU] Still set up the two SGPRs for queue ptr even it is COV5 (#112403)"</title>
<updated>2024-11-08T21:36:35+00:00</updated>
<author>
<name>Shilei Tian</name>
<email>i@tianshilei.me</email>
</author>
<published>2024-11-08T21:36:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ca33649abe5fad93c57afef54e43ed9b3249cd86'/>
<id>ca33649abe5fad93c57afef54e43ed9b3249cd86</id>
<content type='text'>
This reverts commit e215a1e27d84adad2635a52393621eb4fa439dc9 as it broke both
hip and openmp buildbots.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit e215a1e27d84adad2635a52393621eb4fa439dc9 as it broke both
hip and openmp buildbots.
</pre>
</div>
</content>
</entry>
</feed>
