<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Transforms/InstCombine/InstCombineVectorOps.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>[InstCombine] Pull unary shuffles through fneg/fabs (#144933)</title>
<updated>2025-06-30T09:40:12+00:00</updated>
<author>
<name>Luke Lau</name>
<email>luke@igalia.com</email>
</author>
<published>2025-06-30T09:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d0c1ea928c5c4a99689ff3dcbf1ca578d56b80a3'/>
<id>d0c1ea928c5c4a99689ff3dcbf1ca578d56b80a3</id>
<content type='text'>
This canonicalizes fneg/fabs (shuffle X, poison, mask) -&gt; shuffle
(fneg/fabs X), posion, mask

This undoes part of b331a7ebc1e02f9939d1a4a1509e7eb6cdda3d38 and
a8f13dbdeb31be37ee15b5febb7cc2137bbece67, but keeps the binary shuffle
case i.e. shuffle fneg, fneg, mask.

By pulling out the shuffle we bring it inline with the same
canonicalisation we perform on binary ops and intrinsics, which the
original commit acknowledges it goes in the opposite direction.

However nowadays VectorCombine is more powerful and can do more
optimisations when the shuffle is pulled out, so I think we should
revisit this. In particular we get more shuffles folded and can perform
scalarization.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This canonicalizes fneg/fabs (shuffle X, poison, mask) -&gt; shuffle
(fneg/fabs X), posion, mask

This undoes part of b331a7ebc1e02f9939d1a4a1509e7eb6cdda3d38 and
a8f13dbdeb31be37ee15b5febb7cc2137bbece67, but keeps the binary shuffle
case i.e. shuffle fneg, fneg, mask.

By pulling out the shuffle we bring it inline with the same
canonicalisation we perform on binary ops and intrinsics, which the
original commit acknowledges it goes in the opposite direction.

However nowadays VectorCombine is more powerful and can do more
optimisations when the shuffle is pulled out, so I think we should
revisit this. In particular we get more shuffles folded and can perform
scalarization.
</pre>
</div>
</content>
</entry>
<entry>
<title>[ValueTracking] Make Depth last default arg (NFC) (#142384)</title>
<updated>2025-06-03T16:12:24+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2025-06-03T16:12:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b40e4ceaa61c5f14ca261e2952e7f85a066403e2'/>
<id>b40e4ceaa61c5f14ca261e2952e7f85a066403e2</id>
<content type='text'>
Having a finite Depth (or recursion limit) for computeKnownBits is very
limiting, but is currently a load-bearing necessity, as all KnownBits
are recomputed on each call and there is no caching. As a prerequisite
for an effort to remove the recursion limit altogether, either using a
clever caching technique, or writing a easily-invalidable KnownBits
analysis, make the Depth argument in APIs in ValueTracking uniformly the
last argument with a default value. This would aid in removing the
argument when the time comes, as many callers that currently pass 0
explicitly are now updated to omit the argument altogether.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Having a finite Depth (or recursion limit) for computeKnownBits is very
limiting, but is currently a load-bearing necessity, as all KnownBits
are recomputed on each call and there is no caching. As a prerequisite
for an effort to remove the recursion limit altogether, either using a
clever caching technique, or writing a easily-invalidable KnownBits
analysis, make the Depth argument in APIs in ValueTracking uniformly the
last argument with a default value. This would aid in removing the
argument when the time comes, as many callers that currently pass 0
explicitly are now updated to omit the argument altogether.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Value-initialize values with *Map::try_emplace (NFC) (#141522)</title>
<updated>2025-05-26T22:13:02+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-05-26T22:13:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=89308de4b0f4f20c685c6d9cecd6dabe117080b4'/>
<id>89308de4b0f4f20c685c6d9cecd6dabe117080b4</id>
<content type='text'>
try_emplace value-initializes values, so we do not need to pass
nullptr to try_emplace when the value types are raw pointers or
std::unique_ptr&lt;T&gt;.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
try_emplace value-initializes values, so we do not need to pass
nullptr to try_emplace when the value types are raw pointers or
std::unique_ptr&lt;T&gt;.</pre>
</div>
</content>
</entry>
<entry>
<title>[InstCombine] Preserve GEP no-wrap flags (#141113)</title>
<updated>2025-05-22T21:48:33+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2025-05-22T21:48:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f398f2aadcc48849d491839a4e31bc3d4ad08758'/>
<id>f398f2aadcc48849d491839a4e31bc3d4ad08758</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[InstCombine] Do not combine shuffle+bitcast if the bitcast is eliminable. (#135769)</title>
<updated>2025-04-30T07:22:38+00:00</updated>
<author>
<name>Ricardo Jesus</name>
<email>rjj@nvidia.com</email>
</author>
<published>2025-04-30T07:22:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c91c3f930cfc75eb4e8b623ecd59c807863aa6c0'/>
<id>c91c3f930cfc75eb4e8b623ecd59c807863aa6c0</id>
<content type='text'>
If we are attempting to combine shuffle+bitcast but the bitcast is
pairable with a subsequent bitcast, we should not fold the shuffle as
doing so can block further simplifications.

The motivation for this is a long-standing regression affecting SIMDe on
AArch64, introduced indirectly by the AlwaysInliner (1a2e77cf). Some
reproducers:
* https://godbolt.org/z/53qx18s6M
* https://godbolt.org/z/o5e43h5M7</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we are attempting to combine shuffle+bitcast but the bitcast is
pairable with a subsequent bitcast, we should not fold the shuffle as
doing so can block further simplifications.

The motivation for this is a long-standing regression affecting SIMDe on
AArch64, introduced indirectly by the AlwaysInliner (1a2e77cf). Some
reproducers:
* https://godbolt.org/z/53qx18s6M
* https://godbolt.org/z/o5e43h5M7</pre>
</div>
</content>
</entry>
<entry>
<title>[InstCombine] Use MapVector for SourceAggregates. (#132564)</title>
<updated>2025-03-23T11:16:50+00:00</updated>
<author>
<name>Florian Hahn</name>
<email>flo@fhahn.com</email>
</author>
<published>2025-03-23T11:16:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cfd53ffb44f5d3c438c909b2bc9ae5604f452f39'/>
<id>cfd53ffb44f5d3c438c909b2bc9ae5604f452f39</id>
<content type='text'>
foldAggregateConstructionIntoAggregateReuse iterates over the entries of
SourceAggregates and the order of inserted instructions depends on the
order of the iterator. Using a regular DenseMap can lead to
non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes
diffing IR more difficult.

PR: https://github.com/llvm/llvm-project/pull/132564</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
foldAggregateConstructionIntoAggregateReuse iterates over the entries of
SourceAggregates and the order of inserted instructions depends on the
order of the iterator. Using a regular DenseMap can lead to
non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes
diffing IR more difficult.

PR: https://github.com/llvm/llvm-project/pull/132564</pre>
</div>
</content>
</entry>
<entry>
<title>[InstCombine] Avoid repeated hash lookups (NFC) (#124243)</title>
<updated>2025-01-24T16:09:20+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-01-24T16:09:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5d2393a222c751723b0906485bf90a28dd4e564b'/>
<id>5d2393a222c751723b0906485bf90a28dd4e564b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)</title>
<updated>2025-01-24T10:53:11+00:00</updated>
<author>
<name>Jeremy Morse</name>
<email>jeremy.morse@sony.com</email>
</author>
<published>2025-01-24T10:53:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8e702735090388a3231a863e343f880d0f96fecb'/>
<id>8e702735090388a3231a863e343f880d0f96fecb</id>
<content type='text'>
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to moveBefore use iterators.

This patch adds a (guaranteed dereferenceable) iterator-taking
moveBefore, and changes a bunch of call-sites where it's obviously safe
to change to use it by just calling getIterator() on an instruction
pointer. A follow-up patch will contain less-obviously-safe changes.

We'll eventually deprecate and remove the instruction-pointer
insertBefore, but not before adding concise documentation of what
considerations are needed (very few).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to moveBefore use iterators.

This patch adds a (guaranteed dereferenceable) iterator-taking
moveBefore, and changes a bunch of call-sites where it's obviously safe
to change to use it by just calling getIterator() on an instruction
pointer. A follow-up patch will contain less-obviously-safe changes.

We'll eventually deprecate and remove the instruction-pointer
insertBefore, but not before adding concise documentation of what
considerations are needed (very few).</pre>
</div>
</content>
</entry>
<entry>
<title>PatternMatch: migrate to CmpPredicate (#118534)</title>
<updated>2024-12-13T14:18:33+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2024-12-13T14:18:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4a0d53a0b0a58a3c6980a7c551357ac71ba3db10'/>
<id>4a0d53a0b0a58a3c6980a7c551357ac71ba3db10</id>
<content type='text'>
With the introduction of CmpPredicate in 51a895a (IR: introduce struct
with CmpInst::Predicate and samesign), PatternMatch is one of the first
key pieces of infrastructure that must be updated to match a CmpInst
respecting samesign information. Implement this change to Cmp-matchers.

This is a preparatory step in migrating the codebase over to
CmpPredicate. Since we no functional changes are desired at this stage,
we have chosen not to migrate CmpPredicate::operator==(CmpPredicate)
calls to use CmpPredicate::getMatching(), as that would have visible
impact on tests that are not yet written: instead, we call
CmpPredicate::operator==(Predicate), preserving the old behavior, while
also inserting a few FIXME comments for follow-ups.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the introduction of CmpPredicate in 51a895a (IR: introduce struct
with CmpInst::Predicate and samesign), PatternMatch is one of the first
key pieces of infrastructure that must be updated to match a CmpInst
respecting samesign information. Implement this change to Cmp-matchers.

This is a preparatory step in migrating the codebase over to
CmpPredicate. Since we no functional changes are desired at this stage,
we have chosen not to migrate CmpPredicate::operator==(CmpPredicate)
calls to use CmpPredicate::getMatching(), as that would have visible
impact on tests that are not yet written: instead, we call
CmpPredicate::operator==(Predicate), preserving the old behavior, while
also inserting a few FIXME comments for follow-ups.</pre>
</div>
</content>
</entry>
<entry>
<title>[InstCombine] Optimistically allow multiple shufflevector uses in foldOpPhi (#114278)</title>
<updated>2024-12-13T01:20:48+00:00</updated>
<author>
<name>Matthias Braun</name>
<email>matze@braunis.de</email>
</author>
<published>2024-12-13T01:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=768754807f17754fb450ec672779b827ad5df4b4'/>
<id>768754807f17754fb450ec672779b827ad5df4b4</id>
<content type='text'>
We would like to optimize situations of the form that happen after loop
vectorization+SROA:
```
loop:
    %phi = phi zeroinitializer, %interleaved

    %deinterleave_a = shufflevector %phi, poison ; pick half of the lanes
    %deinterleave_b = shufflevector %phi, posion ; pick remaining lanes

    ... %a = ... %b = ...

    %interleaved = shufflevector %a, %b ; interleave lanes of a+b
```
where the interleave and de-interleave shuffle operations cancel each
other out.
This could be handled by `foldOpPhi` but does not currently work because
it does
not proceed when there are multiple uses of the `Phi` operation.

This extends `foldOpPhi` to allow multiple `shufflevector` uses when
they are
shown to simplify for all `Phi` input values.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We would like to optimize situations of the form that happen after loop
vectorization+SROA:
```
loop:
    %phi = phi zeroinitializer, %interleaved

    %deinterleave_a = shufflevector %phi, poison ; pick half of the lanes
    %deinterleave_b = shufflevector %phi, posion ; pick remaining lanes

    ... %a = ... %b = ...

    %interleaved = shufflevector %a, %b ; interleave lanes of a+b
```
where the interleave and de-interleave shuffle operations cancel each
other out.
This could be handled by `foldOpPhi` but does not currently work because
it does
not proceed when there are multiple uses of the `Phi` operation.

This extends `foldOpPhi` to allow multiple `shufflevector` uses when
they are
shown to simplify for all `Phi` input values.</pre>
</div>
</content>
</entry>
</feed>
