<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/Transforms/Inline/AMDGPU, 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] Remove explicit datalayout from tests where not needed</title>
<updated>2025-04-30T17:58:17+00:00</updated>
<author>
<name>Alexander Richardson</name>
<email>alexrichardson@google.com</email>
</author>
<published>2025-04-30T17:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ee136383628290f7efa0fc4562beef2b411048bb'/>
<id>ee136383628290f7efa0fc4562beef2b411048bb</id>
<content type='text'>
Since e39f6c1844fab59c638d8059a6cf139adb42279a opt will infer the
correct datalayout when given a triple. Avoid explicitly specifying it
in tests that depend on the AMDGPU target being present to avoid the
string becoming out of sync with the TargetInfo value.
Only tests with REQUIRES: amdgpu-registered-target or a local lit.cfg
were updated to ensure that tests for non-target-specific passes that
happen to use the AMDGPU layout still pass when building with a limited
set of targets.

Reviewed By: shiltian, arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/137921
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since e39f6c1844fab59c638d8059a6cf139adb42279a opt will infer the
correct datalayout when given a triple. Avoid explicitly specifying it
in tests that depend on the AMDGPU target being present to avoid the
string becoming out of sync with the TargetInfo value.
Only tests with REQUIRES: amdgpu-registered-target or a local lit.cfg
were updated to ensure that tests for non-target-specific passes that
happen to use the AMDGPU layout still pass when building with a limited
set of targets.

Reviewed By: shiltian, arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/137921
</pre>
</div>
</content>
</entry>
<entry>
<title>[TTI][AMDGPU] Allow targets to adjust `LastCallToStaticBonus` via `getInliningLastCallToStaticBonus`  (#111311)</title>
<updated>2024-10-11T14:19:54+00:00</updated>
<author>
<name>Shilei Tian</name>
<email>i@tianshilei.me</email>
</author>
<published>2024-10-11T14:19:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e34e27f19820af958db7c3b93de7f489aa3bf4dc'/>
<id>e34e27f19820af958db7c3b93de7f489aa3bf4dc</id>
<content type='text'>
Currently we will not be able to inline a large function even if it only
has one live use because the inline cost is still very high after
applying `LastCallToStaticBonus`, which is a constant. This could
significantly impact the performance because CSR spill is very
expensive.

This PR adds a new function `getInliningLastCallToStaticBonus` to TTI to
allow targets to customize this value.

Fixes SWDEV-471398.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we will not be able to inline a large function even if it only
has one live use because the inline cost is still very high after
applying `LastCallToStaticBonus`, which is a constant. This could
significantly impact the performance because CSR spill is very
expensive.

This PR adds a new function `getInliningLastCallToStaticBonus` to TTI to
allow targets to customize this value.

Fixes SWDEV-471398.</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: Stop handling legacy amdgpu-unsafe-fp-atomics attribute (#101699)</title>
<updated>2024-08-13T18:02:25+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2024-08-13T18:02:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=edded8d7b5cb310524494cca317dd3582234b56f'/>
<id>edded8d7b5cb310524494cca317dd3582234b56f</id>
<content type='text'>
This is now autoupgraded to annotate atomicrmw instructions in
old bitcode.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is now autoupgraded to annotate atomicrmw instructions in
old bitcode.</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: Update name for amdgpu.no.remote.memory metadata</title>
<updated>2024-05-03T09:50:59+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2024-04-22T09:40:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9f9856d623559bcd970b52167f7ac096d76b2659'/>
<id>9f9856d623559bcd970b52167f7ac096d76b2659</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: Add tests for atomicrmw handling of new metadata (#89248)</title>
<updated>2024-04-19T22:43:36+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2024-04-19T22:43:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f433c3b38005701fdc219ae8c01e6af1b8bedba9'/>
<id>f433c3b38005701fdc219ae8c01e6af1b8bedba9</id>
<content type='text'>
Add baseline tests which should comprehensively test the new atomic
metadata. Test codegen / expansion, and preservation in a few
transforms.

New metadata defined in #85052</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add baseline tests which should comprehensively test the new atomic
metadata. Test codegen / expansion, and preservation in a few
transforms.

New metadata defined in #85052</pre>
</div>
</content>
</entry>
<entry>
<title>[InlineCost][TargetTransformInfo][AMDGPU] Consider cost of alloca instructions in the caller (2/2)</title>
<updated>2023-06-29T07:49:16+00:00</updated>
<author>
<name>Juan Manuel MARTINEZ CAAMAÑO</name>
<email>juamarti@amd.com</email>
</author>
<published>2023-06-29T07:31:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dd1df099ae37c2a68a20c96615b7ed7474eacec4'/>
<id>dd1df099ae37c2a68a20c96615b7ed7474eacec4</id>
<content type='text'>
Before this patch, the compiler gave a bump to the inline-threshold
when the total size of the allocas passed as arguments to the
callee was below 256 bytes.
This heuristic ignores that some of these allocas could have be removed
by SROA if inlining was applied.

Ideally, this bonus would be attributed to the threshold once the
size of all the allocas that could not be handled by SROA is known:
at the end of the InlineCost analysis.
However, we may never reach this point if the inline-cost analysis exits
early when the inline cost goes over the threshold mid-analysis.

This patch proposes:
* Attribute the bonus in the inline-threshold when allocas are passed
  as arguments (regardless of their total size).
* Assigns a cost to each alloca proportional to its size,
  such that the cost of all the allocas cancels the bonus.

Potential problems:
* This patch assumes that removing alloca instructions with SROA is
  always profitable. This may not be the case if the total size of the
  allocas is still too big to be promoted to registers/LDS.
* Redundant calls to getTotalAllocaSize
* Awkwardly, the threshold attributed contributes to the single-bb and
  vector bonus.

Reviewed By: scchan

Differential Revision: https://reviews.llvm.org/D149741
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this patch, the compiler gave a bump to the inline-threshold
when the total size of the allocas passed as arguments to the
callee was below 256 bytes.
This heuristic ignores that some of these allocas could have be removed
by SROA if inlining was applied.

Ideally, this bonus would be attributed to the threshold once the
size of all the allocas that could not be handled by SROA is known:
at the end of the InlineCost analysis.
However, we may never reach this point if the inline-cost analysis exits
early when the inline cost goes over the threshold mid-analysis.

This patch proposes:
* Attribute the bonus in the inline-threshold when allocas are passed
  as arguments (regardless of their total size).
* Assigns a cost to each alloca proportional to its size,
  such that the cost of all the allocas cancels the bonus.

Potential problems:
* This patch assumes that removing alloca instructions with SROA is
  always profitable. This may not be the case if the total size of the
  allocas is still too big to be promoted to registers/LDS.
* Redundant calls to getTotalAllocaSize
* Awkwardly, the threshold attributed contributes to the single-bb and
  vector bonus.

Reviewed By: scchan

Differential Revision: https://reviews.llvm.org/D149741
</pre>
</div>
</content>
</entry>
<entry>
<title>Inline: Fix case of not inlining with denormal-fp-math-f32</title>
<updated>2023-06-09T23:09:48+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2023-06-09T22:23:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=19293b82c180660de9636ebe8caa01fe797fb388'/>
<id>19293b82c180660de9636ebe8caa01fe797fb388</id>
<content type='text'>
This was failing to inline the opencl libraries with daz enabled. As a
modifier to the base mode, denormal-fp-mode-f32 is weird and has no
meaning if it's missing.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was failing to inline the opencl libraries with daz enabled. As a
modifier to the base mode, denormal-fp-mode-f32 is weird and has no
meaning if it's missing.
</pre>
</div>
</content>
</entry>
<entry>
<title>AMDGPU: Add inlining testcases for denormal-fp-math</title>
<updated>2023-06-09T23:09:48+00:00</updated>
<author>
<name>Matt Arsenault</name>
<email>Matthew.Arsenault@amd.com</email>
</author>
<published>2023-06-09T22:19:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d0b9cb1f659ffe327acae57be7e1b40473b12b4d'/>
<id>d0b9cb1f659ffe327acae57be7e1b40473b12b4d</id>
<content type='text'>
Somehow missed this one and it's not working correctly
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Somehow missed this one and it's not working correctly
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC][Py Reformat] Reformat lit.local.cfg python files in llvm</title>
<updated>2023-05-17T15:03:15+00:00</updated>
<author>
<name>Tobias Hieta</name>
<email>tobias@hieta.se</email>
</author>
<published>2023-05-17T09:01:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f84bac329ba6c9f0c022bcf77237e912362e247a'/>
<id>f84bac329ba6c9f0c022bcf77237e912362e247a</id>
<content type='text'>
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours &lt;yourfile&gt; and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: barannikov88, kwk

Differential Revision: https://reviews.llvm.org/D150762
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours &lt;yourfile&gt; and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: barannikov88, kwk

Differential Revision: https://reviews.llvm.org/D150762
</pre>
</div>
</content>
</entry>
<entry>
<title>Re-land "[AMDGPU] Define data layout entries for buffers""</title>
<updated>2023-05-03T19:43:56+00:00</updated>
<author>
<name>Krzysztof Drewniak</name>
<email>Krzysztof.Drewniak@amd.com</email>
</author>
<published>2023-05-03T16:21:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f0415f2a456d54daaa231c228d2c9f4ef2ce9b89'/>
<id>f0415f2a456d54daaa231c228d2c9f4ef2ce9b89</id>
<content type='text'>
Re-land D145441 with data layout upgrade code fixed to not break OpenMP.

This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.

Differential Revision: https://reviews.llvm.org/D149776
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Re-land D145441 with data layout upgrade code fixed to not break OpenMP.

This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.

Differential Revision: https://reviews.llvm.org/D149776
</pre>
</div>
</content>
</entry>
</feed>
