<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/Transforms/FunctionAttrs, 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>[FunctionAttrs] Handle ConstantRange overflow in memset initializes inference (#145739)</title>
<updated>2025-07-01T13:04:52+00:00</updated>
<author>
<name>Shivam Gupta</name>
<email>shivam98.tkg@gmail.com</email>
</author>
<published>2025-07-01T13:04:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e44fbea0a17f468d45de5eaef158642f067f678c'/>
<id>e44fbea0a17f468d45de5eaef158642f067f678c</id>
<content type='text'>
Avoid constructing invalid ConstantRange when Offset + Length in memset
overflows signed 64-bit integer space. This prevents assertion failures
when inferring the initializes attribute.

Fixes #140345</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Avoid constructing invalid ConstantRange when Offset + Length in memset
overflows signed 64-bit integer space. This prevents assertion failures
when inferring the initializes attribute.

Fixes #140345</pre>
</div>
</content>
</entry>
<entry>
<title>[FunctionAttrs][IR] Fix memory attr inference for volatile mem intrinsics (#122926)</title>
<updated>2025-06-25T07:29:37+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2025-06-25T07:29:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7c38ee26d44124c93dc1553cde36837928c96d41'/>
<id>7c38ee26d44124c93dc1553cde36837928c96d41</id>
<content type='text'>
Per LangRef volatile operations can read and write inaccessible memory:

&gt; any volatile operation can read and/or modify state which is not
&gt; accessible via a regular load or store in this module

Model this by adding inaccessible memory effects in getMemoryEffects()
if the operation is volatile.

In the future, we should model volatile using operand bundles instead.

Fixes https://github.com/llvm/llvm-project/issues/120932.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per LangRef volatile operations can read and write inaccessible memory:

&gt; any volatile operation can read and/or modify state which is not
&gt; accessible via a regular load or store in this module

Model this by adding inaccessible memory effects in getMemoryEffects()
if the operation is volatile.

In the future, we should model volatile using operand bundles instead.

Fixes https://github.com/llvm/llvm-project/issues/120932.</pre>
</div>
</content>
</entry>
<entry>
<title>Reland "[NVPTX] Unify and extend barrier{.cta} intrinsic support" (#141143)</title>
<updated>2025-05-23T02:38:10+00:00</updated>
<author>
<name>Alex MacLean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-05-23T02:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3a84a4e55d896e573fe175f34c793b0c294dec6b'/>
<id>3a84a4e55d896e573fe175f34c793b0c294dec6b</id>
<content type='text'>
Note: This relands #140615 adding a ".count" suffix to the non-".all"
variants.

Our current intrinsic support for barrier intrinsics is confusing and
incomplete, with multiple intrinsics mapping to the same instruction and
intrinsic names not clearly conveying intrinsic semantics. Further, we
lack support for some variants. This change unifies the IR
representation to a single consistently named set of intrinsics.

- llvm.nvvm.barrier.cta.sync.aligned.all(i32)
- llvm.nvvm.barrier.cta.sync.aligned.count(i32, i32)
- llvm.nvvm.barrier.cta.arrive.aligned.count(i32, i32)
- llvm.nvvm.barrier.cta.sync.all(i32)
- llvm.nvvm.barrier.cta.sync.count(i32, i32)
- llvm.nvvm.barrier.cta.arrive.count(i32, i32)

The following Auto-Upgrade rules are used to maintain compatibility with
IR using the legacy intrinsics:

* llvm.nvvm.barrier0 --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(0)
* llvm.nvvm.barrier.n --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.bar.sync --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.barrier --&gt; llvm.nvvm.barrier.cta.sync.aligned.count(x, y)
* llvm.nvvm.barrier.sync --&gt; llvm.nvvm.barrier.cta.sync.all(x)
* llvm.nvvm.barrier.sync.cnt --&gt; llvm.nvvm.barrier.cta.sync.count(x, y)</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Note: This relands #140615 adding a ".count" suffix to the non-".all"
variants.

Our current intrinsic support for barrier intrinsics is confusing and
incomplete, with multiple intrinsics mapping to the same instruction and
intrinsic names not clearly conveying intrinsic semantics. Further, we
lack support for some variants. This change unifies the IR
representation to a single consistently named set of intrinsics.

- llvm.nvvm.barrier.cta.sync.aligned.all(i32)
- llvm.nvvm.barrier.cta.sync.aligned.count(i32, i32)
- llvm.nvvm.barrier.cta.arrive.aligned.count(i32, i32)
- llvm.nvvm.barrier.cta.sync.all(i32)
- llvm.nvvm.barrier.cta.sync.count(i32, i32)
- llvm.nvvm.barrier.cta.arrive.count(i32, i32)

The following Auto-Upgrade rules are used to maintain compatibility with
IR using the legacy intrinsics:

* llvm.nvvm.barrier0 --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(0)
* llvm.nvvm.barrier.n --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.bar.sync --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.barrier --&gt; llvm.nvvm.barrier.cta.sync.aligned.count(x, y)
* llvm.nvvm.barrier.sync --&gt; llvm.nvvm.barrier.cta.sync.all(x)
* llvm.nvvm.barrier.sync.cnt --&gt; llvm.nvvm.barrier.cta.sync.count(x, y)</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[NVPTX] Unify and extend barrier{.cta} intrinsic support (#140615)"</title>
<updated>2025-05-22T17:28:43+00:00</updated>
<author>
<name>Alex Maclean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-05-22T17:28:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e72d8b25531cb5a4fd1e802bac8c9aa6efee0aa1'/>
<id>e72d8b25531cb5a4fd1e802bac8c9aa6efee0aa1</id>
<content type='text'>
This reverts commit 735209c0688b10a66c24750422b35d8c2ad01bb5.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 735209c0688b10a66c24750422b35d8c2ad01bb5.
</pre>
</div>
</content>
</entry>
<entry>
<title>[NVPTX] Unify and extend barrier{.cta} intrinsic support (#140615)</title>
<updated>2025-05-21T15:14:15+00:00</updated>
<author>
<name>Alex MacLean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-05-21T15:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=735209c0688b10a66c24750422b35d8c2ad01bb5'/>
<id>735209c0688b10a66c24750422b35d8c2ad01bb5</id>
<content type='text'>
Our current intrinsic support for barrier intrinsics is confusing and
incomplete, with multiple intrinsics mapping to the same instruction and
intrinsic names not clearly conveying intrinsic semantics. Further, we
lack support for some variants. This change unifies the IR
representation to a single consistently named set of intrinsics.

- llvm.nvvm.barrier.cta.sync.aligned.all(i32)
- llvm.nvvm.barrier.cta.sync.aligned(i32, i32)
- llvm.nvvm.barrier.cta.arrive.aligned(i32, i32)
- llvm.nvvm.barrier.cta.sync.all(i32)
- llvm.nvvm.barrier.cta.sync(i32, i32)
- llvm.nvvm.barrier.cta.arrive(i32, i32)

The following Auto-Upgrade rules are used to maintain compatibility with
IR using the legacy intrinsics:

* llvm.nvvm.barrier0 --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(0)
* llvm.nvvm.barrier.n --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.bar.sync --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.barrier --&gt; llvm.nvvm.barrier.cta.sync.aligned(x, y)
* llvm.nvvm.barrier.sync --&gt; llvm.nvvm.barrier.cta.sync.all(x)
* llvm.nvvm.barrier.sync.cnt --&gt; llvm.nvvm.barrier.cta.sync(x, y)</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Our current intrinsic support for barrier intrinsics is confusing and
incomplete, with multiple intrinsics mapping to the same instruction and
intrinsic names not clearly conveying intrinsic semantics. Further, we
lack support for some variants. This change unifies the IR
representation to a single consistently named set of intrinsics.

- llvm.nvvm.barrier.cta.sync.aligned.all(i32)
- llvm.nvvm.barrier.cta.sync.aligned(i32, i32)
- llvm.nvvm.barrier.cta.arrive.aligned(i32, i32)
- llvm.nvvm.barrier.cta.sync.all(i32)
- llvm.nvvm.barrier.cta.sync(i32, i32)
- llvm.nvvm.barrier.cta.arrive(i32, i32)

The following Auto-Upgrade rules are used to maintain compatibility with
IR using the legacy intrinsics:

* llvm.nvvm.barrier0 --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(0)
* llvm.nvvm.barrier.n --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.bar.sync --&gt; llvm.nvvm.barrier.cta.sync.aligned.all(x)
* llvm.nvvm.barrier --&gt; llvm.nvvm.barrier.cta.sync.aligned(x, y)
* llvm.nvvm.barrier.sync --&gt; llvm.nvvm.barrier.cta.sync.all(x)
* llvm.nvvm.barrier.sync.cnt --&gt; llvm.nvvm.barrier.cta.sync(x, y)</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Set AS8 address width to 48 bits</title>
<updated>2025-05-20T00:26:05+00:00</updated>
<author>
<name>Alexander Richardson</name>
<email>alexrichardson@google.com</email>
</author>
<published>2025-05-20T00:26:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=07e2ba445df7d277e5195c0ec85b133735ea76e3'/>
<id>07e2ba445df7d277e5195c0ec85b133735ea76e3</id>
<content type='text'>
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic conclusion is to set the index width to 48 bits instead of
the current value of 128.

Most of the test changes are mechanical datalayout updates, but there
is one actual change: the ptrmask test now uses .i48 instead of .i128
and I had to update SelectionDAGBuilder to correctly extend the mask.

Reviewed By: krzysz00

Pull Request: https://github.com/llvm/llvm-project/pull/139419
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic conclusion is to set the index width to 48 bits instead of
the current value of 128.

Most of the test changes are mechanical datalayout updates, but there
is one actual change: the ptrmask test now uses .i48 instead of .i128
and I had to update SelectionDAGBuilder to correctly extend the mask.

Reviewed By: krzysz00

Pull Request: https://github.com/llvm/llvm-project/pull/139419
</pre>
</div>
</content>
</entry>
<entry>
<title>[FunctionAttrs] Only consider provenance capture in access attr inference (#138535)</title>
<updated>2025-05-06T13:42:26+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2025-05-06T13:42:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aec39293316049e5944ac281f800efe5e0dcac5f'/>
<id>aec39293316049e5944ac281f800efe5e0dcac5f</id>
<content type='text'>
For the purpose of inferring readonly/writeonly/readnone on arguments,
we only care about provenance captures, not address captures.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For the purpose of inferring readonly/writeonly/readnone on arguments,
we only care about provenance captures, not address captures.</pre>
</div>
</content>
</entry>
<entry>
<title>[FunctionAttrs] Add test for SCC with address only capture (NFC)</title>
<updated>2025-05-05T13:58:44+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2025-05-05T13:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f33821628d0e03f5389e1f4339b4d10f6a8883b5'/>
<id>f33821628d0e03f5389e1f4339b4d10f6a8883b5</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[IR] Relax convergence requirements on call (#135794)</title>
<updated>2025-05-02T08:17:58+00:00</updated>
<author>
<name>Nathan Gauër</name>
<email>brioche@google.com</email>
</author>
<published>2025-05-02T08:17:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=df344285e260109e016e28a14e663f376d8e903c'/>
<id>df344285e260109e016e28a14e663f376d8e903c</id>
<content type='text'>
Before this commit, having a convergence token on a non-convergent call
was considered to be an error.
This commit relaxes this requirement and allows convergence tokens to be
present on non-convergent calls.

When such token is present, they have no effect as the underlying call
is non-convergent.
This allows passes like DCE to strip `convergent` attribute from
functions for which all convergent operations have been stripped. When
this happens, a convergence token can still exist in the call-site,
causing the verifier to complain.

Alternatives have been considered in #134863 and #134844.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this commit, having a convergence token on a non-convergent call
was considered to be an error.
This commit relaxes this requirement and allows convergence tokens to be
present on non-convergent calls.

When such token is present, they have no effect as the underlying call
is non-convergent.
This allows passes like DCE to strip `convergent` attribute from
functions for which all convergent operations have been stripped. When
this happens, a convergence token can still exist in the call-site,
causing the verifier to complain.

Alternatives have been considered in #134863 and #134844.</pre>
</div>
</content>
</entry>
<entry>
<title>[FunctionAttrs] Bail if initializes range overflows 64-bit signed int (#137053)</title>
<updated>2025-04-23T22:56:24+00:00</updated>
<author>
<name>Arthur Eubanks</name>
<email>aeubanks@google.com</email>
</author>
<published>2025-04-23T22:56:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0547e84181ff10b24d6363bbfc97f168fe245397'/>
<id>0547e84181ff10b24d6363bbfc97f168fe245397</id>
<content type='text'>
Otherwise the range doesn't make sense since we interpret it as signed.

Fixes #134115</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise the range doesn't make sense since we interpret it as signed.

Fixes #134115</pre>
</div>
</content>
</entry>
</feed>
