<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp, 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>[LV] Add support for cmp reductions with decreasing IVs. (#140451)</title>
<updated>2025-06-29T10:17:03+00:00</updated>
<author>
<name>Florian Hahn</name>
<email>flo@fhahn.com</email>
</author>
<published>2025-06-29T10:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=20fbbd76755c2ddee515f09e96c59d519aef13e5'/>
<id>20fbbd76755c2ddee515f09e96c59d519aef13e5</id>
<content type='text'>
Similar to FindLastIV, add FindFirstIVSMin to support select (icmp(), x, y)
reductions where one of x or y is a decreasing induction, producing a SMin
 reduction. It uses signed max as sentinel value.

PR: https://github.com/llvm/llvm-project/pull/140451</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similar to FindLastIV, add FindFirstIVSMin to support select (icmp(), x, y)
reductions where one of x or y is a decreasing induction, producing a SMin
 reduction. It uses signed max as sentinel value.

PR: https://github.com/llvm/llvm-project/pull/140451</pre>
</div>
</content>
</entry>
<entry>
<title>[LV] Extend FindLastIV to unsigned case (#141752)</title>
<updated>2025-06-23T14:27:49+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2025-06-23T14:27:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bb8c42e859871aaf6bbec78dee28f124d47348dd'/>
<id>bb8c42e859871aaf6bbec78dee28f124d47348dd</id>
<content type='text'>
Split the FindLastIV RecurKind into SMax and UMax variants, depending on
the reduction op produced.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Split the FindLastIV RecurKind into SMax and UMax variants, depending on
the reduction op produced.</pre>
</div>
</content>
</entry>
<entry>
<title>[CostModel] Add a DstTy to getShuffleCost (#141634)</title>
<updated>2025-06-21T11:29:29+00:00</updated>
<author>
<name>David Green</name>
<email>david.green@arm.com</email>
</author>
<published>2025-06-21T11:29:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=77941eba7f01fc6576b3e060a3fb9cad1a64f9ea'/>
<id>77941eba7f01fc6576b3e060a3fb9cad1a64f9ea</id>
<content type='text'>
A shuffle will take two input vectors and a mask, to produce a new
vector of size &lt;MaskElts x SrcEltTy&gt;. Historically it has been assumed
that the SrcTy and the DstTy are the same for getShuffleCost, with that
being relaxed in recent years. If the Tp passed to getShuffleCost is the
SrcTy, then the DstTy can be calculated from the Mask elts and the src
elt size, but the Mask is not always provided and the Tp is not reliably
always the SrcTy. This has led to situations notably in the SLP
vectorizer but also in the generic cost routines where assumption about
how vectors will be legalized are built into the generic cost routines -
for example whether they will widen or promote, with the cost modelling
assuming they will widen but the default lowering to promote for integer
vectors.

This patch attempts to start improving that - it originally tried to
alter more of the cost model but that too quickly became too many
changes at once, so this patch just plumbs in a DstTy to getShuffleCost
so that DstTy and SrcTy can be reliably distinguished. The callers of
getShuffleCost have been updated to try and include a DstTy that is more
accurate. Otherwise it tries to be fairly non-functional, keeping the
SrcTy used as the primary type used in shuffle cost routines, only using
DstTy where it was in the past (for InsertSubVector for example).

Some asserts have been added that help to check for consistent values
when a Mask and a DstTy are provided to getShuffleCost. Some of them
took a while to get right, and some non-mask calls might still be
incorrect. Hopefully this will provide a useful base to build more
shuffles that alter size.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A shuffle will take two input vectors and a mask, to produce a new
vector of size &lt;MaskElts x SrcEltTy&gt;. Historically it has been assumed
that the SrcTy and the DstTy are the same for getShuffleCost, with that
being relaxed in recent years. If the Tp passed to getShuffleCost is the
SrcTy, then the DstTy can be calculated from the Mask elts and the src
elt size, but the Mask is not always provided and the Tp is not reliably
always the SrcTy. This has led to situations notably in the SLP
vectorizer but also in the generic cost routines where assumption about
how vectors will be legalized are built into the generic cost routines -
for example whether they will widen or promote, with the cost modelling
assuming they will widen but the default lowering to promote for integer
vectors.

This patch attempts to start improving that - it originally tried to
alter more of the cost model but that too quickly became too many
changes at once, so this patch just plumbs in a DstTy to getShuffleCost
so that DstTy and SrcTy can be reliably distinguished. The callers of
getShuffleCost have been updated to try and include a DstTy that is more
accurate. Otherwise it tries to be fairly non-functional, keeping the
SrcTy used as the primary type used in shuffle cost routines, only using
DstTy where it was in the past (for InsertSubVector for example).

Some asserts have been added that help to check for consistent values
when a Mask and a DstTy are provided to getShuffleCost. Some of them
took a while to get right, and some non-mask calls might still be
incorrect. Hopefully this will provide a useful base to build more
shuffles that alter size.</pre>
</div>
</content>
</entry>
<entry>
<title>[SLP] NFC: Simplify CandidateVFs initialization (#144882)</title>
<updated>2025-06-20T09:00:55+00:00</updated>
<author>
<name>Sander de Smalen</name>
<email>sander.desmalen@arm.com</email>
</author>
<published>2025-06-20T09:00:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=874773635d31501ab21812c05c44caf281c1acc7'/>
<id>874773635d31501ab21812c05c44caf281c1acc7</id>
<content type='text'>
Also adds a comment to clarify the meaning of MaxRegVF.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Also adds a comment to clarify the meaning of MaxRegVF.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Migrate away from ArrayRef(std::nullopt) (NFC) (#144967)</title>
<updated>2025-06-20T04:31:26+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-20T04:31:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=64fe3236476a9a85977abf5489414bbb2de2109c'/>
<id>64fe3236476a9a85977abf5489414bbb2de2109c</id>
<content type='text'>
ArrayRef has a constructor that accepts std::nullopt.  This
constructor dates back to the days when we still had llvm::Optional.

Since the use of std::nullopt outside the context of std::optional is
kind of abuse and not intuitive to new comers, I would like to move
away from the constructor and eventually remove it.

This patch takes care of the llvm side of the migration.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ArrayRef has a constructor that accepts std::nullopt.  This
constructor dates back to the days when we still had llvm::Optional.

Since the use of std::nullopt outside the context of std::optional is
kind of abuse and not intuitive to new comers, I would like to move
away from the constructor and eventually remove it.

This patch takes care of the llvm side of the migration.</pre>
</div>
</content>
</entry>
<entry>
<title>[SLP]Fix a crash on an subvector size calculation for non-power-of-2 vector</title>
<updated>2025-06-17T15:58:07+00:00</updated>
<author>
<name>Alexey Bataev</name>
<email>a.bataev@outlook.com</email>
</author>
<published>2025-06-17T14:55:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0108a5908cab5e418c683ef9b6e1810755344b5e'/>
<id>0108a5908cab5e418c683ef9b6e1810755344b5e</id>
<content type='text'>
Patch fixes cost estimation for the extractelements from non-power-of-2
vectors, defined as subvector extracts. In this case the subvector size
might be not adjusted to a whole register size, need to get the minimum
between whole vector size and the actual difference to prevent compiler
crash.

Fixes #143513
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Patch fixes cost estimation for the extractelements from non-power-of-2
vectors, defined as subvector extracts. In this case the subvector size
might be not adjusted to a whole register size, need to get the minimum
between whole vector size and the actual difference to prevent compiler
crash.

Fixes #143513
</pre>
</div>
</content>
</entry>
<entry>
<title>[SLPVectorizer] Use accurate cost for external users of resize shuffles (#137419)</title>
<updated>2025-06-17T15:14:05+00:00</updated>
<author>
<name>Jeffrey Byrnes</name>
<email>jeffrey.byrnes@amd.com</email>
</author>
<published>2025-06-17T15:14:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c9a87a50aee3c91f36d33c170d5131bcc370c289'/>
<id>c9a87a50aee3c91f36d33c170d5131bcc370c289</id>
<content type='text'>
When implementing the vectorization, we potentially need to add shuffles
for external users. In such cases, we may be shuffling a smaller vector
into a larger vector. When this happens `ResizeToVF` will just build a
poison padded identity vector. Then the to build the final shuffle, we
just use the `SK_InsertSubvector` mask.

This is possibly clearer by looking at the included test in
SLPVectorizer/AMDGPU/external-shuffle.ll

In the exit block we have a bunch of shuffles to glue the vectorized
tree match the `InsertElement` users. `TMP25` holds the result of
resizing the v2i16 vectorized sequence to match the `InsertElement` size
v16i16. Then `TMP26` is the final shuffle which replaces the
`InsertElement` sequence. This is just an insertsubvector.

However, when calculating the cost for these shuffles, we aren't
modelling this correctly. `ResizeToVF` will indicate to
`performExtractsShuffleAction` that we cannot use the original mask due
to the resize shuffle. The consequence is that the cost calculation uses
a different shuffle mask than what is ultimately used.

Going back to the included test, we can consider again `TMP26`. Clearly
we can see the shuffle uses a mask {0, 1, 2, 3, 16, 17, poison ..}.
However, we will currently calculate the cost with a mask {0, 1, 2, 3,
20, 21, ...} we have replaced 16 and 17 with 20 and 21 (Index + Vector
Size). Queries like BasicTTImpl::improveShuffleKindFromMask will not
recognize this as an `SK_InsertSubvector` mask, and targets which have
reduced costs for `SK_InsertSubvector` will not accurately calculate the
cost.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When implementing the vectorization, we potentially need to add shuffles
for external users. In such cases, we may be shuffling a smaller vector
into a larger vector. When this happens `ResizeToVF` will just build a
poison padded identity vector. Then the to build the final shuffle, we
just use the `SK_InsertSubvector` mask.

This is possibly clearer by looking at the included test in
SLPVectorizer/AMDGPU/external-shuffle.ll

In the exit block we have a bunch of shuffles to glue the vectorized
tree match the `InsertElement` users. `TMP25` holds the result of
resizing the v2i16 vectorized sequence to match the `InsertElement` size
v16i16. Then `TMP26` is the final shuffle which replaces the
`InsertElement` sequence. This is just an insertsubvector.

However, when calculating the cost for these shuffles, we aren't
modelling this correctly. `ResizeToVF` will indicate to
`performExtractsShuffleAction` that we cannot use the original mask due
to the resize shuffle. The consequence is that the cost calculation uses
a different shuffle mask than what is ultimately used.

Going back to the included test, we can consider again `TMP26`. Clearly
we can see the shuffle uses a mask {0, 1, 2, 3, 16, 17, poison ..}.
However, we will currently calculate the cost with a mask {0, 1, 2, 3,
20, 21, ...} we have replaced 16 and 17 with 20 and 21 (Index + Vector
Size). Queries like BasicTTImpl::improveShuffleKindFromMask will not
recognize this as an `SK_InsertSubvector` mask, and targets which have
reduced costs for `SK_InsertSubvector` will not accurately calculate the
cost.</pre>
</div>
</content>
</entry>
<entry>
<title>[DebugInfo][RemoveDIs] Remove a swathe of debug-intrinsic code (#144389)</title>
<updated>2025-06-17T14:55:14+00:00</updated>
<author>
<name>Jeremy Morse</name>
<email>jeremy.morse@sony.com</email>
</author>
<published>2025-06-17T14:55:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9eb0020555fc643582b2802abb8c1bc92059c248'/>
<id>9eb0020555fc643582b2802abb8c1bc92059c248</id>
<content type='text'>
Seeing how we can't generate any debug intrinsics any more: delete a
variety of codepaths where they're handled. For the most part these are
plain deletions, in others I've tweaked comments to remain coherent, or
added a type to (what was) type-generic-lambdas.

This isn't all the DbgInfoIntrinsic call sites but it's most of the
simple scenarios.

Co-authored-by: Nikita Popov &lt;github@npopov.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Seeing how we can't generate any debug intrinsics any more: delete a
variety of codepaths where they're handled. For the most part these are
plain deletions, in others I've tweaked comments to remain coherent, or
added a type to (what was) type-generic-lambdas.

This isn't all the DbgInfoIntrinsic call sites but it's most of the
simple scenarios.

Co-authored-by: Nikita Popov &lt;github@npopov.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[SLP] Fix isCommutative to check uses of the original instruction instead of the converted instruction. (#143094)</title>
<updated>2025-06-17T14:03:14+00:00</updated>
<author>
<name>Han-Kuan Chen</name>
<email>hankuan.chen@sifive.com</email>
</author>
<published>2025-06-17T14:03:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=414710c753d87d314529857e15d1ad01a76c6605'/>
<id>414710c753d87d314529857e15d1ad01a76c6605</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[SLP] vectorizeStores: Name things a bit more clearly (NFC) (#144511)</title>
<updated>2025-06-17T12:20:52+00:00</updated>
<author>
<name>Gaëtan Bossu</name>
<email>gaetan.bossu@arm.com</email>
</author>
<published>2025-06-17T12:20:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=087d83e0c6d94c1ad6a68b089950d05185d0e043'/>
<id>087d83e0c6d94c1ad6a68b089950d05185d0e043</id>
<content type='text'>
I believe the new variable names better convey their purpose. However, I
also believe that function is more complex than it needs to be, and this
tiny patch should be seen as a first step towards (maybe) further
refactoring.

The previous names were very generic (Size, Sz, Cnt, StartIdx). This
made it easy to get confused given that the vecotrizeStores() function
is already complex enough.

My hope would be to eventually have a function concise enough to clearly
see what are the different strategies being attempted to vectorise a
group of related store instructions.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I believe the new variable names better convey their purpose. However, I
also believe that function is more complex than it needs to be, and this
tiny patch should be seen as a first step towards (maybe) further
refactoring.

The previous names were very generic (Size, Sz, Cnt, StartIdx). This
made it easy to get confused given that the vecotrizeStores() function
is already complex enough.

My hope would be to eventually have a function concise enough to clearly
see what are the different strategies being attempted to vectorise a
group of related store instructions.</pre>
</div>
</content>
</entry>
</feed>
