<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/Transforms/StraightLineStrengthReduce, 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>[NVPTX] Remove Float register classes (#140487)</title>
<updated>2025-05-21T18:33:57+00:00</updated>
<author>
<name>Alex MacLean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-05-21T18:33:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=76c9bfefa416f66a3fe79164874e13a612e00415'/>
<id>76c9bfefa416f66a3fe79164874e13a612e00415</id>
<content type='text'>
These classes are redundant, as the untyped "Int" classes can be used
for all float operations. This change is intended to be as minimal as
possible and leaves the many potential simplifications and refactors
this exposes as future work.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These classes are redundant, as the untyped "Int" classes can be used
for all float operations. This change is intended to be as minimal as
possible and leaves the many potential simplifications and refactors
this exposes as future work.</pre>
</div>
</content>
</entry>
<entry>
<title>[NVPTX] use untyped loads and stores where ever possible (#137698)</title>
<updated>2025-05-10T15:26:26+00:00</updated>
<author>
<name>Alex MacLean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-05-10T15:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=369891b6747e4ad4b5e4e6d06f3f7596f3ee3f02'/>
<id>369891b6747e4ad4b5e4e6d06f3f7596f3ee3f02</id>
<content type='text'>
In most cases, the type information attached to load and store
instructions is meaningless and inconsistently applied. We can usually
use ".b" loads and avoid the complexity of trying to assign the correct
type. The one expectation is sign-extending load, which will continue to
use ".s" to ensure the sign extension into a larger register is done
correctly.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In most cases, the type information attached to load and store
instructions is meaningless and inconsistently applied. We can usually
use ".b" loads and avoid the complexity of trying to assign the correct
type. The one expectation is sign-extending load, which will continue to
use ".s" to ensure the sign extension into a larger register is done
correctly.</pre>
</div>
</content>
</entry>
<entry>
<title>[SeparateConstOffsetFromGEP] Don't set unsound inbounds flag (#130616)</title>
<updated>2025-03-18T11:30:20+00:00</updated>
<author>
<name>Fabian Ritter</name>
<email>fabian.ritter@amd.com</email>
</author>
<published>2025-03-18T11:30:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=332f0603635d06986d6d3c8c9ba4fee04c7cab18'/>
<id>332f0603635d06986d6d3c8c9ba4fee04c7cab18</id>
<content type='text'>
The language reference says about inbounds geps that "if the
getelementptr has any non-zero indices[...] [t]he base pointer has an in
bounds address of the allocated object that it is based on [and]
[d]uring the successive addition of offsets to the address, the
resulting pointer must remain in bounds of the allocated object at each
step."

If (gep inbounds p, (a + 5)) is translated to (gep [inbounds] (gep p,
a), 5) with p pointing to the beginning of an object and a=-4, as the
example in the comments suggests, that's the case for neither of the
resulting geps. Therefore, we need to clear the inbounds flag for both
geps.

We might want to use ValueTracking to check if a is known to be
non-negative to preserve the inbounds flags.

For the AMDGPU tests with scratch instructions, removing the unsound
inbounds flag means that AMDGPUDAGToDAGISel::isFlatScratchBaseLegal sees
no NUW flag at the pointer add, which prevents generation of scratch
instructions with immediate offsets.

For SWDEV-516125.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The language reference says about inbounds geps that "if the
getelementptr has any non-zero indices[...] [t]he base pointer has an in
bounds address of the allocated object that it is based on [and]
[d]uring the successive addition of offsets to the address, the
resulting pointer must remain in bounds of the allocated object at each
step."

If (gep inbounds p, (a + 5)) is translated to (gep [inbounds] (gep p,
a), 5) with p pointing to the beginning of an object and a=-4, as the
example in the comments suggests, that's the case for neither of the
resulting geps. Therefore, we need to clear the inbounds flag for both
geps.

We might want to use ValueTracking to check if a is known to be
non-negative to preserve the inbounds flags.

For the AMDGPU tests with scratch instructions, removing the unsound
inbounds flag means that AMDGPUDAGToDAGISel::isFlatScratchBaseLegal sees
no NUW flag at the pointer add, which prevents generation of scratch
instructions with immediate offsets.

For SWDEV-516125.</pre>
</div>
</content>
</entry>
<entry>
<title>[NVPTX] Switch front-ends and tests to ptx_kernel cc (#120806)</title>
<updated>2025-01-08T02:24:50+00:00</updated>
<author>
<name>Alex MacLean</name>
<email>amaclean@nvidia.com</email>
</author>
<published>2025-01-08T02:24:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4583f6d3443c8dc6605c868724e3743161954210'/>
<id>4583f6d3443c8dc6605c868724e3743161954210</id>
<content type='text'>
the `ptx_kernel` calling convention is a more idiomatic and standard way
of specifying a NVPTX kernel than using the metadata which is not
supposed to change the meaning of the program. Further, checking the
calling convention is significantly faster than traversing the metadata,
improving compile time.

This change updates the clang and mlir frontends as well as the
NVPTXCtorDtorLowering pass to emit kernels using the calling convention.
In addition, this updates all NVPTX unit tests to use the calling
convention as well.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the `ptx_kernel` calling convention is a more idiomatic and standard way
of specifying a NVPTX kernel than using the metadata which is not
supposed to change the meaning of the program. Further, checking the
calling convention is significantly faster than traversing the metadata,
improving compile time.

This change updates the clang and mlir frontends as well as the
NVPTXCtorDtorLowering pass to emit kernels using the calling convention.
In addition, this updates all NVPTX unit tests to use the calling
convention as well.</pre>
</div>
</content>
</entry>
<entry>
<title>[test] Remove redundant -march= when target triple is specified in IR</title>
<updated>2024-12-15T20:42:17+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2024-12-15T20:42:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=133352feb30605ec51b15f77826ed3a2fbf8db56'/>
<id>133352feb30605ec51b15f77826ed3a2fbf8db56</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)</title>
<updated>2024-11-06T11:53:33+00:00</updated>
<author>
<name>Paul Walker</name>
<email>paul.walker@arm.com</email>
</author>
<published>2024-11-06T11:53:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=38fffa630ee80163dc65e759392ad29798905679'/>
<id>38fffa630ee80163dc65e759392ad29798905679</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[SeparateConstOffsetFromGEP] Always emit i8 gep</title>
<updated>2024-01-10T10:57:28+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-01-10T10:41:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9e5a77f252badfc932d1e28ee998746072ddc33f'/>
<id>9e5a77f252badfc932d1e28ee998746072ddc33f</id>
<content type='text'>
Always emit canonical i8 GEPs, don't try to preserve the original
element type. As this is a backend pass, trying to preserve the
type is not useful.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Always emit canonical i8 GEPs, don't try to preserve the original
element type. As this is a backend pass, trying to preserve the
type is not useful.
</pre>
</div>
</content>
</entry>
<entry>
<title>[SLSR] Always generate i8 GEPs</title>
<updated>2024-01-10T10:31:27+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-01-10T10:12:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9bc4355f091b530625ec6839a8c4858b6de4f1b4'/>
<id>9bc4355f091b530625ec6839a8c4858b6de4f1b4</id>
<content type='text'>
Always generate canonical i8 GEPs. Especially as this is a backend
pass, trying to generate a "nice" GEP representation is not useful.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Always generate canonical i8 GEPs. Especially as this is a backend
pass, trying to generate a "nice" GEP representation is not useful.
</pre>
</div>
</content>
</entry>
<entry>
<title>[SLSR] Regenerate test checks (NFC)</title>
<updated>2024-01-10T10:14:51+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-01-10T10:14:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=76482b74400cccae10d30195f6613f2bf538a43f'/>
<id>76482b74400cccae10d30195f6613f2bf538a43f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</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>
</feed>
