<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp, branch main</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>Re-land [Transform][LoadStoreVectorizer] allow redundant in Chain (#168135)</title>
<updated>2025-11-20T01:39:10+00:00</updated>
<author>
<name>Gang Chen</name>
<email>gangc@amd.com</email>
</author>
<published>2025-11-20T01:39:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9e9fe08b16ea2c4d9867fb4974edf2a3776d6ece'/>
<id>9e9fe08b16ea2c4d9867fb4974edf2a3776d6ece</id>
<content type='text'>
This is the fixed version of
https://github.com/llvm/llvm-project/pull/163019</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the fixed version of
https://github.com/llvm/llvm-project/pull/163019</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[Transform][LoadStoreVectorizer] allow redundant in Chain (#1… (#168105)</title>
<updated>2025-11-14T19:49:09+00:00</updated>
<author>
<name>Gang Chen</name>
<email>gangc@amd.com</email>
</author>
<published>2025-11-14T19:49:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a407d02752f9d28fe01dd2fe5cdc12344ab38753'/>
<id>a407d02752f9d28fe01dd2fe5cdc12344ab38753</id>
<content type='text'>
…63019)"

This reverts commit 92e5608ffa6ff39ac3707f29418cc9482471f5d9.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
…63019)"

This reverts commit 92e5608ffa6ff39ac3707f29418cc9482471f5d9.</pre>
</div>
</content>
</entry>
<entry>
<title>[Transform][LoadStoreVectorizer] allow redundant in Chain (#163019)</title>
<updated>2025-11-13T20:19:29+00:00</updated>
<author>
<name>Gang Chen</name>
<email>gangc@amd.com</email>
</author>
<published>2025-11-13T20:19:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=92e5608ffa6ff39ac3707f29418cc9482471f5d9'/>
<id>92e5608ffa6ff39ac3707f29418cc9482471f5d9</id>
<content type='text'>
This can absorb redundant loads when forming vector load. Can be used to
fix the situation created by VectorCombine. See:
https://discourse.llvm.org/t/what-is-the-purpose-of-vectorizeloadinsert-in-the-vectorcombine-pass/88532</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This can absorb redundant loads when forming vector load. Can be used to
fix the situation created by VectorCombine. See:
https://discourse.llvm.org/t/what-is-the-purpose-of-vectorizeloadinsert-in-the-vectorcombine-pass/88532</pre>
</div>
</content>
</entry>
<entry>
<title>[LoadStoreVectorizer] Batch alias analysis results to improve compile time (#147555)</title>
<updated>2025-07-10T16:23:33+00:00</updated>
<author>
<name>Drew Kersnar</name>
<email>dkersnar@nvidia.com</email>
</author>
<published>2025-07-10T16:23:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8e7461e29a7c9f1721758b30eb99b0ccab45a7cd'/>
<id>8e7461e29a7c9f1721758b30eb99b0ccab45a7cd</id>
<content type='text'>
This should be generally good for a lot of LSV cases, but the attached
test demonstrates a specific compile time issue that appears in the
event where the `CaptureTracking` default max uses is raised.

Without using batching alias analysis, this test takes 6 seconds to
compile in a release build. With, less than a second. This is because
the mechanism that proves `NoAlias` in this case is very expensive
(`CaptureTracking.cpp`), and caching the result leads to 2 calls to that
mechanism instead of ~300,000 (run with -stats to see the difference)

This test only demonstrates the compile time issue if
`capture-tracking-max-uses-to-explore` is set to at least 1024, because
with the default value of 100, the `CaptureTracking` analysis is not
run, `NoAlias` is not proven, and the vectorizer gives up early.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This should be generally good for a lot of LSV cases, but the attached
test demonstrates a specific compile time issue that appears in the
event where the `CaptureTracking` default max uses is raised.

Without using batching alias analysis, this test takes 6 seconds to
compile in a release build. With, less than a second. This is because
the mechanism that proves `NoAlias` in this case is very expensive
(`CaptureTracking.cpp`), and caching the result leads to 2 calls to that
mechanism instead of ~300,000 (run with -stats to see the difference)

This test only demonstrates the compile time issue if
`capture-tracking-max-uses-to-explore` is set to at least 1024, because
with the default value of 100, the `CaptureTracking` analysis is not
run, `NoAlias` is not proven, and the vectorizer gives up early.</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>[NFC] Cleanup dead code in `LoadStoreVectorizer.cpp` (#139211)</title>
<updated>2025-05-09T07:28:10+00:00</updated>
<author>
<name>Iris Shi</name>
<email>0.0@owo.li</email>
</author>
<published>2025-05-09T07:28:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5f530b134ca6a87f2a6cb0f29fadcd3fbd0cf962'/>
<id>5f530b134ca6a87f2a6cb0f29fadcd3fbd0cf962</id>
<content type='text'>
Closes #138691</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Closes #138691</pre>
</div>
</content>
</entry>
<entry>
<title>[Vectorize] Avoid repeated hash lookups (NFC) (#126345)</title>
<updated>2025-02-08T08:48:51+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-02-08T08:48:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5901bda5a0ed31e024abc8a7af52b272400daa08'/>
<id>5901bda5a0ed31e024abc8a7af52b272400daa08</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>[LoadStoreVectorizer] Postprocess and merge equivalence classes (#121861)</title>
<updated>2025-01-08T01:17:26+00:00</updated>
<author>
<name>Vyacheslav Klochkov</name>
<email>vyacheslav.n.klochkov@intel.com</email>
</author>
<published>2025-01-08T01:17:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9184c42869b87a59839cafdb8a3679e7ec2faeb1'/>
<id>9184c42869b87a59839cafdb8a3679e7ec2faeb1</id>
<content type='text'>
This patch introduces a new method:

void Vectorizer::mergeEquivalenceClasses(EquivalenceClassMap &amp;EQClasses)
const;

The method is called at the end of
Vectorizer::collectEquivalenceClasses() and is needed to merge
equivalence classes that differ only by their underlying objects (UO1
and UO2), where UO1 is 1-level-indirection underlying base for UO2. This
situation arises due to the limited lookup depth used during the search
of underlying bases with llvm::getUnderlyingObject(ptr).

Using any fixed lookup depth can result into creation of multiple
equivalence classes that only differ by 1-level indirection bases.

The new approach merges equivalence classes if they have adjacent bases
(1-level indirection). If a series of equivalence classes form ladder
formed of 1-step/level indirections, they are all merged into a single
equivalence class. This provides more opportunities for the load-store
vectorizer to generate better vectors.

---------

Signed-off-by: Klochkov, Vyacheslav N &lt;vyacheslav.n.klochkov@intel.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch introduces a new method:

void Vectorizer::mergeEquivalenceClasses(EquivalenceClassMap &amp;EQClasses)
const;

The method is called at the end of
Vectorizer::collectEquivalenceClasses() and is needed to merge
equivalence classes that differ only by their underlying objects (UO1
and UO2), where UO1 is 1-level-indirection underlying base for UO2. This
situation arises due to the limited lookup depth used during the search
of underlying bases with llvm::getUnderlyingObject(ptr).

Using any fixed lookup depth can result into creation of multiple
equivalence classes that only differ by 1-level indirection bases.

The new approach merges equivalence classes if they have adjacent bases
(1-level indirection). If a series of equivalence classes form ladder
formed of 1-step/level indirections, they are all merged into a single
equivalence class. This provides more opportunities for the load-store
vectorizer to generate better vectors.

---------

Signed-off-by: Klochkov, Vyacheslav N &lt;vyacheslav.n.klochkov@intel.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[LoadStoreVectorizer] Postprocess and merge equivalence classes" (#119657)</title>
<updated>2024-12-12T04:36:23+00:00</updated>
<author>
<name>Michal Paszkowski</name>
<email>michal@paszkowski.org</email>
</author>
<published>2024-12-12T04:36:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=04313b86a52541b2a618d14f7fa1f23ea7adfa47'/>
<id>04313b86a52541b2a618d14f7fa1f23ea7adfa47</id>
<content type='text'>
Reverts llvm/llvm-project#114501, due to the following failure:
https://lab.llvm.org/buildbot/#/builders/55/builds/4171</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#114501, due to the following failure:
https://lab.llvm.org/buildbot/#/builders/55/builds/4171</pre>
</div>
</content>
</entry>
</feed>
