<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/Transforms/VectorCombine/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>[VectorCombine] vectorizeLoadInsert - only fold when inserting into a poison vector (#119906)</title>
<updated>2024-12-14T11:56:12+00:00</updated>
<author>
<name>Simon Pilgrim</name>
<email>llvm-dev@redking.me.uk</email>
</author>
<published>2024-12-14T11:56:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cc54a0ce5674b740c2136d7bd2416ffeb4a230cf'/>
<id>cc54a0ce5674b740c2136d7bd2416ffeb4a230cf</id>
<content type='text'>
We have corresponding poison tests in the "-inseltpoison.ll" sibling test files.

Fixes #119900</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have corresponding poison tests in the "-inseltpoison.ll" sibling test files.

Fixes #119900</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>
<entry>
<title>Revert "[AMDGPU] Define data layout entries for buffers"</title>
<updated>2023-05-03T16:11:00+00:00</updated>
<author>
<name>Krzysztof Drewniak</name>
<email>Krzysztof.Drewniak@amd.com</email>
</author>
<published>2023-05-03T16:08:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27'/>
<id>3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27</id>
<content type='text'>
This reverts commit f9c1ede2543b37fabe9f2d8f8fed5073c475d850.

Differential Revision: https://reviews.llvm.org/D149758
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit f9c1ede2543b37fabe9f2d8f8fed5073c475d850.

Differential Revision: https://reviews.llvm.org/D149758
</pre>
</div>
</content>
</entry>
<entry>
<title>[AMDGPU] Define data layout entries for buffers</title>
<updated>2023-05-03T15:25:58+00:00</updated>
<author>
<name>Krzysztof Drewniak</name>
<email>Krzysztof.Drewniak@amd.com</email>
</author>
<published>2023-02-07T20:37:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f9c1ede2543b37fabe9f2d8f8fed5073c475d850'/>
<id>f9c1ede2543b37fabe9f2d8f8fed5073c475d850</id>
<content type='text'>
Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new address spaces for AMDGCN targets.

The first is address space 7, a non-integral address space (which was
already in the data layout) that has 160-bit pointers (which are
256-bit aligned) and uses a 32-bit offset. These pointers combine a
128-bit buffer descriptor and a 32-bit offset, and will be usable with
normal LLVM operations (load, store, GEP). However, they will be
rewritten out of existence before code generation.

The second of these is address space 8, the address space for "buffer
resources". These will be used to represent the resource arguments to
buffer instructions, and new buffer intrinsics will be defined that
take them instead of &lt;4 x i32&gt; as resource arguments. ptr
addrspace(8). These pointers are 128-bits long (with the same
alignment). They must not be used as the arguments to getelementptr or
otherwise used in address computations, since they can have
arbitrarily complex inherent addressing semantics that can't be
represented in LLVM. Even though, like their address space 7 cousins,
these pointers have deterministic ptrtoint/inttoptr semantics, they
are defined to be non-integral in order to prevent optimizations that
rely on pointers being a [0, [addr_max]] value from applying to them.

Future work includes:
- Defining new buffer intrinsics that take ptr addrspace(8) resources.
- A late rewrite to turn address space 7 operations into buffer
intrinsics and offset computations.

This commit also updates the "fallback address space" for buffer
intrinsics to the buffer resource, and updates the alias analysis
table.

Depends on D143437

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D145441
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new address spaces for AMDGCN targets.

The first is address space 7, a non-integral address space (which was
already in the data layout) that has 160-bit pointers (which are
256-bit aligned) and uses a 32-bit offset. These pointers combine a
128-bit buffer descriptor and a 32-bit offset, and will be usable with
normal LLVM operations (load, store, GEP). However, they will be
rewritten out of existence before code generation.

The second of these is address space 8, the address space for "buffer
resources". These will be used to represent the resource arguments to
buffer instructions, and new buffer intrinsics will be defined that
take them instead of &lt;4 x i32&gt; as resource arguments. ptr
addrspace(8). These pointers are 128-bits long (with the same
alignment). They must not be used as the arguments to getelementptr or
otherwise used in address computations, since they can have
arbitrarily complex inherent addressing semantics that can't be
represented in LLVM. Even though, like their address space 7 cousins,
these pointers have deterministic ptrtoint/inttoptr semantics, they
are defined to be non-integral in order to prevent optimizations that
rely on pointers being a [0, [addr_max]] value from applying to them.

Future work includes:
- Defining new buffer intrinsics that take ptr addrspace(8) resources.
- A late rewrite to turn address space 7 operations into buffer
intrinsics and offset computations.

This commit also updates the "fallback address space" for buffer
intrinsics to the buffer resource, and updates the alias analysis
table.

Depends on D143437

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D145441
</pre>
</div>
</content>
</entry>
<entry>
<title>[IR] Change shufflevector undef mask to poison</title>
<updated>2023-04-27T13:41:10+00:00</updated>
<author>
<name>ManuelJBrito</name>
<email>manuel.brito@tecnico.ulisboa.pt</email>
</author>
<published>2023-04-26T13:19:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8b56da5e9f3ba737a5ff4bf5dee654416849042f'/>
<id>8b56da5e9f3ba737a5ff4bf5dee654416849042f</id>
<content type='text'>
With this patch an undefined mask in a shufflevector will be printed as poison.
This change is done to support the new shufflevector semantics
for undefined mask elements.

Differential Revision: https://reviews.llvm.org/D149210
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With this patch an undefined mask in a shufflevector will be printed as poison.
This change is done to support the new shufflevector semantics
for undefined mask elements.

Differential Revision: https://reviews.llvm.org/D149210
</pre>
</div>
</content>
</entry>
<entry>
<title>[VectorCombine] Convert tests to opaque pointers (NFC)</title>
<updated>2022-12-23T09:04:26+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2022-12-23T09:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c00ffbe02b222ec34a0181436c17025a2dfacedc'/>
<id>c00ffbe02b222ec34a0181436c17025a2dfacedc</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[VectorCombine] Insert addrspacecast when crossing address space boundaries</title>
<updated>2022-03-24T19:08:08+00:00</updated>
<author>
<name>Fraser Cormack</name>
<email>fraser@codeplay.com</email>
</author>
<published>2022-03-16T10:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2e44b7872bc638ed884ae4aa86e38b3b47e0b65a'/>
<id>2e44b7872bc638ed884ae4aa86e38b3b47e0b65a</id>
<content type='text'>
We can not bitcast pointers across different address spaces. This was
previously fixed in D89577 but then in D93229 an enhancement was added
which peeks further through the ponter operand, opening up the
possibility that address-space violations could be introduced.

Instead of bailing as the previous fix did, simply insert an
addrspacecast cast instruction.

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D121787
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We can not bitcast pointers across different address spaces. This was
previously fixed in D89577 but then in D93229 an enhancement was added
which peeks further through the ponter operand, opening up the
possibility that address-space violations could be introduced.

Instead of bailing as the previous fix did, simply insert an
addrspacecast cast instruction.

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D121787
</pre>
</div>
</content>
</entry>
<entry>
<title>[NewPM][test] Use -passes syntax in VectorCombine lit tests</title>
<updated>2021-10-20T13:16:17+00:00</updated>
<author>
<name>Bjorn Pettersson</name>
<email>bjorn.a.pettersson@ericsson.com</email>
</author>
<published>2021-10-20T12:47:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5e4dbd7a2fb095a6c25ec4758b806571c033e88e'/>
<id>5e4dbd7a2fb095a6c25ec4758b806571c033e88e</id>
<content type='text'>
The legacy PM is deprecated, so use the new PM syntax in lit tests
running the vector-combine pass.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The legacy PM is deprecated, so use the new PM syntax in lit tests
running the vector-combine pass.
</pre>
</div>
</content>
</entry>
</feed>
