<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Target/WebAssembly/WebAssemblyTargetTransformInfo.cpp, branch users/mingmingl-llvm/samplefdo-profile-format</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>[WebAssembly] Implement getInterleavedMemoryOpCost (#146864)</title>
<updated>2025-08-27T11:43:52+00:00</updated>
<author>
<name>Sam Parker</name>
<email>sam.parker@arm.com</email>
</author>
<published>2025-08-27T11:43:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7b3e77f8d94c9abda1675c62f70caf12e3d7d5ce'/>
<id>7b3e77f8d94c9abda1675c62f70caf12e3d7d5ce</id>
<content type='text'>
First pass where we calculate the cost of the memory operation, as well
as the shuffles required. Interleaving by a factor of two should be
relatively cheap, as many ISAs have dedicated instructions to perform
the (de)interleaving. Several of these permutations can be combined for
an interleave stride of 4 and this is the highest stride we allow.

I've costed larger vectors, and more lanes, as more expensive because
not only is more work is needed but the risk of codegen going 'wrong'
rises dramatically. I also filled in a bit of cost modelling for vector
stores.

It appears the main vector plan to avoid is an interleave factor of 4
with v16i8. I've used libyuv and ncnn for benchmarking, using V8 on
AArch64, and observe geomean improvement of ~3% with some kernels
improving 40-60%.

I know there is still significant performance being left on the table,
so this will need more development along with the rest of the cost
model.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
First pass where we calculate the cost of the memory operation, as well
as the shuffles required. Interleaving by a factor of two should be
relatively cheap, as many ISAs have dedicated instructions to perform
the (de)interleaving. Several of these permutations can be combined for
an interleave stride of 4 and this is the highest stride we allow.

I've costed larger vectors, and more lanes, as more expensive because
not only is more work is needed but the risk of codegen going 'wrong'
rises dramatically. I also filled in a bit of cost modelling for vector
stores.

It appears the main vector plan to avoid is an interleave factor of 4
with v16i8. I've used libyuv and ncnn for benchmarking, using V8 on
AArch64, and observe geomean improvement of ~3% with some kernels
improving 40-60%.

I know there is still significant performance being left on the table,
so this will need more development along with the rest of the cost
model.</pre>
</div>
</content>
</entry>
<entry>
<title>[WebAssembly] Reapply #149461 with correct CondCode in combine of SETCC (#153703)</title>
<updated>2025-08-15T19:06:47+00:00</updated>
<author>
<name>Jasmine Tang</name>
<email>jjasmine@igalia.com</email>
</author>
<published>2025-08-15T19:06:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d7a29e5d5605f277d991b03a3923597a033d73ed'/>
<id>d7a29e5d5605f277d991b03a3923597a033d73ed</id>
<content type='text'>
This PR reapplies https://github.com/llvm/llvm-project/pull/149461

In the original `combineVectorSizedSetCCEquality`, the result of setcc
is being negated by returning setcc with the same cond code, leading to
wrong logic.

For example, with
```llvm
 %cmp_16 = call i32 @memcmp(ptr %a, ptr %b, i32 16)
  %res = icmp eq i32 %cmp_16, 0
```

the original PR producese all_true and then also compares the result
equal to 0 (using the same SETEQ in the returning setcc), meaning that
semantically, it effectively is calling icmp ne.

Instead, the PR should have use SETNE in the returning setcc, this way,
all true return 1, then it is compared again ne 0, which is equivalent
to icmp eq.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR reapplies https://github.com/llvm/llvm-project/pull/149461

In the original `combineVectorSizedSetCCEquality`, the result of setcc
is being negated by returning setcc with the same cond code, leading to
wrong logic.

For example, with
```llvm
 %cmp_16 = call i32 @memcmp(ptr %a, ptr %b, i32 16)
  %res = icmp eq i32 %cmp_16, 0
```

the original PR producese all_true and then also compares the result
equal to 0 (using the same SETEQ in the returning setcc), meaning that
semantically, it effectively is calling icmp ne.

Instead, the PR should have use SETNE in the returning setcc, this way,
all true return 1, then it is compared again ne 0, which is equivalent
to icmp eq.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[WebAssembly] Combine i128 to v16i8 for setcc &amp; expand memcmp for 16 byte loads with simd128" (#153360)</title>
<updated>2025-08-13T07:41:44+00:00</updated>
<author>
<name>Jasmine Tang</name>
<email>jjasmine@igalia.com</email>
</author>
<published>2025-08-13T07:41:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d32793ca6e19e7b23fe0fa3fd1d550ecc919b9ed'/>
<id>d32793ca6e19e7b23fe0fa3fd1d550ecc919b9ed</id>
<content type='text'>
Reverts llvm/llvm-project#149461

The first test w/ memcmp in `test/neon/test_neon_wasm_simd.cpp` in the
Emscripten test suite has failed. This PR applies a revert so I can take
a closer look at it

Test case link:
https://github.com/emscripten-core/emscripten/blob/main/test/neon/test_neon_wasm_simd.cpp

Compile option: `em++ test_neon_wasm_simd.cpp -O2 -mfpu=neon -msimd128
-o something.js`

Original comment report:
https://github.com/llvm/llvm-project/pull/149461#issuecomment-3181652746</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#149461

The first test w/ memcmp in `test/neon/test_neon_wasm_simd.cpp` in the
Emscripten test suite has failed. This PR applies a revert so I can take
a closer look at it

Test case link:
https://github.com/emscripten-core/emscripten/blob/main/test/neon/test_neon_wasm_simd.cpp

Compile option: `em++ test_neon_wasm_simd.cpp -O2 -mfpu=neon -msimd128
-o something.js`

Original comment report:
https://github.com/llvm/llvm-project/pull/149461#issuecomment-3181652746</pre>
</div>
</content>
</entry>
<entry>
<title>[WebAssembly] Combine i128 to v16i8 for setcc &amp; expand memcmp for 16 byte loads with simd128 (#149461)</title>
<updated>2025-08-12T18:04:37+00:00</updated>
<author>
<name>Jasmine Tang</name>
<email>jjasmine@igalia.com</email>
</author>
<published>2025-08-12T18:04:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=348f01f89c272c08e46bbdc1779d658323f17214'/>
<id>348f01f89c272c08e46bbdc1779d658323f17214</id>
<content type='text'>
Fixes https://github.com/llvm/llvm-project/issues/149230

Previously, even with simd enabled via `-mattr=+simd128`, the compiler
cannot utilize v128 to optimize loads and setcc of i128, instead
legalizing it to consecutive i64s.

This PR then adds support for setcc of i128 by converting them to
v16i8's anytrue and alltrue; consequently, this benefits memcmp of 16
bytes or more (when simd128 is present).

The check for enabling this optimization is if the comparison operand is
either a load or an integer in i128, with the comparison code being
either `EQ | NE`, without `NoImplicitFloat` function flag.

Inspiration taken from RISCV's isel lowering.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes https://github.com/llvm/llvm-project/issues/149230

Previously, even with simd enabled via `-mattr=+simd128`, the compiler
cannot utilize v128 to optimize loads and setcc of i128, instead
legalizing it to consecutive i64s.

This PR then adds support for setcc of i128 by converting them to
v16i8's anytrue and alltrue; consequently, this benefits memcmp of 16
bytes or more (when simd128 is present).

The check for enabling this optimization is if the comparison operand is
either a load or an integer in i128, with the comparison code being
either `EQ | NE`, without `NoImplicitFloat` function flag.

Inspiration taken from RISCV's isel lowering.</pre>
</div>
</content>
</entry>
<entry>
<title>[WebAssembly] Add support for memcmp expansion (#148298)</title>
<updated>2025-07-20T17:27:42+00:00</updated>
<author>
<name>Jasmine Tang</name>
<email>jjasmine@igalia.com</email>
</author>
<published>2025-07-20T17:27:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=343f7475bed009e31ad1d5655f462d53e46ca9fa'/>
<id>343f7475bed009e31ad1d5655f462d53e46ca9fa</id>
<content type='text'>
Fixes https://github.com/llvm/llvm-project/issues/61400

Added test case in llvm/test/CodeGen/WebAssembly/memcmp-expand.ll</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes https://github.com/llvm/llvm-project/issues/61400

Added test case in llvm/test/CodeGen/WebAssembly/memcmp-expand.ll</pre>
</div>
</content>
</entry>
<entry>
<title>[TTI] Plumb CostKind through getPartialReductionCost (#144953)</title>
<updated>2025-06-19T22:29:56+00:00</updated>
<author>
<name>Philip Reames</name>
<email>preames@rivosinc.com</email>
</author>
<published>2025-06-19T22:29:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b96370131d1572feb9c51442ac8ba1ccb16d7071'/>
<id>b96370131d1572feb9c51442ac8ba1ccb16d7071</id>
<content type='text'>
Purely for the sake of being idiomatic with other TTI costing routines,
no direct motivation beyond that.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Purely for the sake of being idiomatic with other TTI costing routines,
no direct motivation beyond that.</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Use more isa and isa_and_nonnull instead dyn_cast for predicates (#137393)</title>
<updated>2025-05-13T14:34:42+00:00</updated>
<author>
<name>Max Graey</name>
<email>maxgraey@gmail.com</email>
</author>
<published>2025-05-13T14:34:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8aaac80ddde6a23527d3caa98ec998ebe402e0d9'/>
<id>8aaac80ddde6a23527d3caa98ec998ebe402e0d9</id>
<content type='text'>
Also fix some typos in comments

---------

Co-authored-by: Mehdi Amini &lt;joker.eph@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Also fix some typos in comments

---------

Co-authored-by: Mehdi Amini &lt;joker.eph@gmail.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[CostModel] Make Op0 and Op1 const in getVectorInstrCost. NFC (#137631)</title>
<updated>2025-05-01T14:55:08+00:00</updated>
<author>
<name>David Green</name>
<email>david.green@arm.com</email>
</author>
<published>2025-05-01T14:55:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=abd2c07e390c39830296ee70d4743663b02dc8df'/>
<id>abd2c07e390c39830296ee70d4743663b02dc8df</id>
<content type='text'>
This does not alter much at the moment, but allows const pointers to be
passed as Op0 and Op1, simplifying later patches</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This does not alter much at the moment, but allows const pointers to be
passed as Op0 and Op1, simplifying later patches</pre>
</div>
</content>
</entry>
<entry>
<title>[TTI] Fix discrepancies in prototypes between interface and implementations (NFCI) (#136655)</title>
<updated>2025-04-22T08:40:12+00:00</updated>
<author>
<name>Sergei Barannikov</name>
<email>barannikov88@gmail.com</email>
</author>
<published>2025-04-22T08:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3334c3597dd51f5a102e5005738e3bf4ef7530e2'/>
<id>3334c3597dd51f5a102e5005738e3bf4ef7530e2</id>
<content type='text'>
These are not diagnosed because implementations hide the methods of the base class rather than overriding them.
This works as long as a hiding function is callable with the same arguments as the same function from the base class.

Pull Request: https://github.com/llvm/llvm-project/pull/136655
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are not diagnosed because implementations hide the methods of the base class rather than overriding them.
This works as long as a hiding function is callable with the same arguments as the same function from the base class.

Pull Request: https://github.com/llvm/llvm-project/pull/136655
</pre>
</div>
</content>
</entry>
<entry>
<title>[TTI] Constify BasicTTIImplBase::thisT() (NFCI) (#136575)</title>
<updated>2025-04-21T18:42:40+00:00</updated>
<author>
<name>Sergei Barannikov</name>
<email>barannikov88@gmail.com</email>
</author>
<published>2025-04-21T18:42:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e0c1e23b99e9719d0a01ab7dfc0807d891004bd4'/>
<id>e0c1e23b99e9719d0a01ab7dfc0807d891004bd4</id>
<content type='text'>
The main change is making `thisT` method `const`, the rest of the
changes is fixing compilation errors (*).

(*) There are two tricky methods, `getVectorInstrCost()` and
`getIntImmCost()`.
They have several overloads; some of these overloads are typically
pulled in to derived classes using the `using` directive, and then
hidden by methods in the derived class.
The compiler does not complain if the hiding methods are not marked as
`const`, which means that clients will use the methods from the base
class. If after this change your target fails cost model tests, this
must be the reason. To resolve the issue you need  to make all hiding
overloads `const`. See the second commit in this PR.

Pull Request: https://github.com/llvm/llvm-project/pull/136575
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The main change is making `thisT` method `const`, the rest of the
changes is fixing compilation errors (*).

(*) There are two tricky methods, `getVectorInstrCost()` and
`getIntImmCost()`.
They have several overloads; some of these overloads are typically
pulled in to derived classes using the `using` directive, and then
hidden by methods in the derived class.
The compiler does not complain if the hiding methods are not marked as
`const`, which means that clients will use the methods from the base
class. If after this change your target fails cost model tests, this
must be the reason. To resolve the issue you need  to make all hiding
overloads `const`. See the second commit in this PR.

Pull Request: https://github.com/llvm/llvm-project/pull/136575
</pre>
</div>
</content>
</entry>
</feed>
