<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/Transforms/LoopStrengthReduce, 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>[PHIElimination] Revert #131837 #146320 #146337 (#146850)</title>
<updated>2025-07-03T11:48:08+00:00</updated>
<author>
<name>Guy David</name>
<email>49722543+guy-david@users.noreply.github.com</email>
</author>
<published>2025-07-03T11:48:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=76274eb2b3439aac6991c6b505248e00627e5693'/>
<id>76274eb2b3439aac6991c6b505248e00627e5693</id>
<content type='text'>
Reverting because mis-compiles:
- https://github.com/llvm/llvm-project/pull/131837
- https://github.com/llvm/llvm-project/pull/146320
- https://github.com/llvm/llvm-project/pull/146337</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverting because mis-compiles:
- https://github.com/llvm/llvm-project/pull/131837
- https://github.com/llvm/llvm-project/pull/146320
- https://github.com/llvm/llvm-project/pull/146337</pre>
</div>
</content>
</entry>
<entry>
<title>[PHIElimination] Reuse existing COPY in predecessor basic block (#131837)</title>
<updated>2025-06-29T18:28:42+00:00</updated>
<author>
<name>Guy David</name>
<email>49722543+guy-david@users.noreply.github.com</email>
</author>
<published>2025-06-29T18:28:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f5c62ee0fa0466382cb11f6fad80d323b0fca057'/>
<id>f5c62ee0fa0466382cb11f6fad80d323b0fca057</id>
<content type='text'>
The insertion point of COPY isn't always optimal and could eventually
lead to a worse block layout, see the regression test in the first
commit.

This change affects many architectures but the amount of total
instructions in the test cases seems too be slightly lower.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The insertion point of COPY isn't always optimal and could eventually
lead to a worse block layout, see the regression test in the first
commit.

This change affects many architectures but the amount of total
instructions in the test cases seems too be slightly lower.</pre>
</div>
</content>
</entry>
<entry>
<title>[LSR] Make canHoistIVInc allow non-integer types (#143707)</title>
<updated>2025-06-16T14:23:40+00:00</updated>
<author>
<name>John Brawn</name>
<email>john.brawn@arm.com</email>
</author>
<published>2025-06-16T14:23:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a54712c8ec25a94ab55a4783bfd9d5467d2ec968'/>
<id>a54712c8ec25a94ab55a4783bfd9d5467d2ec968</id>
<content type='text'>
canHoistIVInc was made to only allow integer types to avoid a crash in
isIndexedLoadLegal/isIndexedStoreLegal due to them failing an assertion
in getValueType (or rather in MVT::getVT which gets called from that)
when passed a struct type. Adjusting these functions to pass
AllowUnknown=true to getValueType means we don't get an assertion
failure (MVT::Other is returned which TLI-&gt;isIndexedLoadLegal should
then return false for), meaning we can remove this check for integer
type.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
canHoistIVInc was made to only allow integer types to avoid a crash in
isIndexedLoadLegal/isIndexedStoreLegal due to them failing an assertion
in getValueType (or rather in MVT::getVT which gets called from that)
when passed a struct type. Adjusting these functions to pass
AllowUnknown=true to getValueType means we don't get an assertion
failure (MVT::Other is returned which TLI-&gt;isIndexedLoadLegal should
then return false for), meaning we can remove this check for integer
type.</pre>
</div>
</content>
</entry>
<entry>
<title>MachineScheduler: Improve instruction clustering (#137784)</title>
<updated>2025-06-05T07:28:04+00:00</updated>
<author>
<name>Ruiling, Song</name>
<email>ruiling.song@amd.com</email>
</author>
<published>2025-06-05T07:28:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0487db1f130913d4fad18483e305b843636ec4ce'/>
<id>0487db1f130913d4fad18483e305b843636ec4ce</id>
<content type='text'>
The existing way of managing clustered nodes was done through adding
weak edges between the neighbouring cluster nodes, which is a sort of
ordered queue. And this will be later recorded as `NextClusterPred` or
`NextClusterSucc` in `ScheduleDAGMI`.

But actually the instruction may be picked not in the exact order of the
queue. For example, we have a queue of cluster nodes A B C. But during
scheduling, node B might be picked first, then it will be very likely
that we only cluster B and C for Top-Down scheduling (leaving A alone).

Another issue is:
```
   if (!ReorderWhileClustering &amp;&amp; SUa-&gt;NodeNum &gt; SUb-&gt;NodeNum)
      std::swap(SUa, SUb);
   if (!DAG-&gt;addEdge(SUb, SDep(SUa, SDep::Cluster)))
```
may break the cluster queue.

For example, we want to cluster nodes (order as in `MemOpRecords`): 1 3
2. 1(SUa) will be pred of 3(SUb) normally. But when it comes to (3, 2),
As 3(SUa) &gt; 2(SUb), we would reorder the two nodes, which makes 2 be
pred of 3. This makes both 1 and 2 become preds of 3, but there is no
edge between 1 and 2. Thus we get a broken cluster chain.

To fix both issues, we introduce an unordered set in the change. This
could help improve clustering in some hard case.

One key reason the change causes so many test check changes is: As the
cluster candidates are not ordered now, the candidates might be picked
in different order from before.

The most affected targets are: AMDGPU, AArch64, RISCV.

For RISCV, it seems to me most are just minor instruction reorder, don't
see obvious regression.

For AArch64, there were some combining of ldr into ldp being affected.
With two cases being regressed and two being improved. This has more
deeper reason that machine scheduler cannot cluster them well both
before and after the change, and the load combine algorithm later is
also not smart enough.

For AMDGPU, some cases have more v_dual instructions used while some are
regressed. It seems less critical. Seems like test `v_vselect_v32bf16`
gets more buffer_load being claused.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The existing way of managing clustered nodes was done through adding
weak edges between the neighbouring cluster nodes, which is a sort of
ordered queue. And this will be later recorded as `NextClusterPred` or
`NextClusterSucc` in `ScheduleDAGMI`.

But actually the instruction may be picked not in the exact order of the
queue. For example, we have a queue of cluster nodes A B C. But during
scheduling, node B might be picked first, then it will be very likely
that we only cluster B and C for Top-Down scheduling (leaving A alone).

Another issue is:
```
   if (!ReorderWhileClustering &amp;&amp; SUa-&gt;NodeNum &gt; SUb-&gt;NodeNum)
      std::swap(SUa, SUb);
   if (!DAG-&gt;addEdge(SUb, SDep(SUa, SDep::Cluster)))
```
may break the cluster queue.

For example, we want to cluster nodes (order as in `MemOpRecords`): 1 3
2. 1(SUa) will be pred of 3(SUb) normally. But when it comes to (3, 2),
As 3(SUa) &gt; 2(SUb), we would reorder the two nodes, which makes 2 be
pred of 3. This makes both 1 and 2 become preds of 3, but there is no
edge between 1 and 2. Thus we get a broken cluster chain.

To fix both issues, we introduce an unordered set in the change. This
could help improve clustering in some hard case.

One key reason the change causes so many test check changes is: As the
cluster candidates are not ordered now, the candidates might be picked
in different order from before.

The most affected targets are: AMDGPU, AArch64, RISCV.

For RISCV, it seems to me most are just minor instruction reorder, don't
see obvious regression.

For AArch64, there were some combining of ldr into ldp being affected.
With two cases being regressed and two being improved. This has more
deeper reason that machine scheduler cannot cluster them well both
before and after the change, and the load combine algorithm later is
also not smart enough.

For AMDGPU, some cases have more v_dual instructions used while some are
regressed. It seems less critical. Seems like test `v_vselect_v32bf16`
gets more buffer_load being claused.</pre>
</div>
</content>
</entry>
<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>[AArch64][SVE] Fold ADD+CNTB to INCB/DECB (#118280)</title>
<updated>2025-04-17T07:41:17+00:00</updated>
<author>
<name>Ricardo Jesus</name>
<email>rjj@nvidia.com</email>
</author>
<published>2025-04-17T07:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=34f9ddf1ce2d775d8df1ca9c9806710f3ba8361d'/>
<id>34f9ddf1ce2d775d8df1ca9c9806710f3ba8361d</id>
<content type='text'>
Currently, given:
```cpp
uint64_t incb(uint64_t x) {
  return x+svcntb();
}
```
LLVM generates:
```gas
incb:
        addvl   x0, x0, #1
        ret
```
Which is equivalent to:
```gas
incb:
        incb    x0
        ret
```

However, on microarchitectures like the Neoverse V2 and Neoverse V3,
the second form (with INCB) can have significantly better latency and
throughput (according to their SWOG). On the Neoverse V2, for example,
ADDVL has a latency and throughput of 2, whereas some forms of INCB
have a latency of 1 and a throughput of 4. The same applies to DECB.
This patch adds patterns to prefer the cheaper INCB/DECB forms over
ADDVL where applicable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, given:
```cpp
uint64_t incb(uint64_t x) {
  return x+svcntb();
}
```
LLVM generates:
```gas
incb:
        addvl   x0, x0, #1
        ret
```
Which is equivalent to:
```gas
incb:
        incb    x0
        ret
```

However, on microarchitectures like the Neoverse V2 and Neoverse V3,
the second form (with INCB) can have significantly better latency and
throughput (according to their SWOG). On the Neoverse V2, for example,
ADDVL has a latency and throughput of 2, whereas some forms of INCB
have a latency of 1 and a throughput of 4. The same applies to DECB.
This patch adds patterns to prefer the cheaper INCB/DECB forms over
ADDVL where applicable.
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Set EnableLoopTermFold (#133454)</title>
<updated>2025-03-29T13:51:59+00:00</updated>
<author>
<name>YunQiang Su</name>
<email>syq@debian.org</email>
</author>
<published>2025-03-29T13:51:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1c7ab39f3d6959c64d01c8f275d672bd56315155'/>
<id>1c7ab39f3d6959c64d01c8f275d672bd56315155</id>
<content type='text'>
Setting `EnableLoopTermFold` enables `loop-term-fold` pass.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Setting `EnableLoopTermFold` enables `loop-term-fold` pass.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "MIPS: Set EnableLoopTermFold (#133378)"</title>
<updated>2025-03-28T11:31:56+00:00</updated>
<author>
<name>Weaver</name>
<email>Tom.Weaver@sony.com</email>
</author>
<published>2025-03-28T11:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=af150272cff97c121ed4fdb76fce702fbe2f12a3'/>
<id>af150272cff97c121ed4fdb76fce702fbe2f12a3</id>
<content type='text'>
This reverts commit 71f43a7c42a37d18be98b0885d62ef76e658f242.

Caused build bot failures:
https://lab.llvm.org/buildbot/#/builders/190/builds/17267
https://lab.llvm.org/buildbot/#/builders/144/builds/21445
https://lab.llvm.org/buildbot/#/builders/46/builds/14343

please consider fixing the test failure in long-array-initialize.ll before
recommitting.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 71f43a7c42a37d18be98b0885d62ef76e658f242.

Caused build bot failures:
https://lab.llvm.org/buildbot/#/builders/190/builds/17267
https://lab.llvm.org/buildbot/#/builders/144/builds/21445
https://lab.llvm.org/buildbot/#/builders/46/builds/14343

please consider fixing the test failure in long-array-initialize.ll before
recommitting.
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Set EnableLoopTermFold (#133378)</title>
<updated>2025-03-28T08:49:45+00:00</updated>
<author>
<name>YunQiang Su</name>
<email>syq@debian.org</email>
</author>
<published>2025-03-28T08:49:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=71f43a7c42a37d18be98b0885d62ef76e658f242'/>
<id>71f43a7c42a37d18be98b0885d62ef76e658f242</id>
<content type='text'>
Setting `EnableLoopTermFold` enables `loop-term-fold` pass.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Setting `EnableLoopTermFold` enables `loop-term-fold` pass.</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Implements MipsTTIImpl::isLSRCostLess using Insns as first (#133068)</title>
<updated>2025-03-26T15:01:26+00:00</updated>
<author>
<name>YunQiang Su</name>
<email>yunqiang@isrc.iscas.ac.cn</email>
</author>
<published>2025-03-26T15:01:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6dd14c881cd6dbe76a73b60ab7eabf95f92271c4'/>
<id>6dd14c881cd6dbe76a73b60ab7eabf95f92271c4</id>
<content type='text'>
So that LoopStrengthReduce can work for MIPS.
The code is copied from RISC-V.

---------

Co-authored-by: qethu &lt;190734095+qethu@users.noreply.github.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
So that LoopStrengthReduce can work for MIPS.
The code is copied from RISC-V.

---------

Co-authored-by: qethu &lt;190734095+qethu@users.noreply.github.com&gt;</pre>
</div>
</content>
</entry>
</feed>
