llvm / llvm/llvm-project

[SLP][X86] Why is this byte-pack reduction profitable when modeled block throughput worsens?

Open
#215,975 5 comments 0 reactions 1 assignee Claimed by @RKSimon View on GitHub
backend:X86 backend:X86 Scheduler Models
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

example : https://compiler-explorer.com/z/3xKh5P95x

`this issue can reproduce currently llvm upstream.`

With current LLVM (`9fcb06786b26dc223786ab9f85ec753d852e768e`), the
`src_pack4_i8_be_shift_var_step` reproducer from #201107 is SLP-vectorized on
`x86-64-v4` into a `<4 x i8>` load, `<4 x i64>` variable shift, and
`llvm.vector.reduce.or`.

The SLP remark reports:

```text
Vectorized horizontal reduction with cost -6 and with tree size 6
```

I lowered the original IR directly, current `default`, and
`default` with SLP disabled. I then ran LLVM-MCA for 100 iterations after
removing only the final `retq` from every assembly. `vzeroupper` and all other
instructions were retained.

| Variant | Instructions | Total Cycles | Total uOps | Block RThroughput |
|--------------------------------|-------------:|-------------:|-----------:|------------------:|
| Original, direct llc -O2 | 19 | 509 | 19 | 3.2 |
| default, SLP disabled | 15 | 287 | 15 | 2.5 |
| Current default with SLP | 11 | 416 | 16 | 4.0 |

Instructions and uOps are per iteration; Total Cycles covers 100 iterations.
Lower Block RThroughput is better.

Commands:

```bash
opt -S '-passes=default' \
-mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64-v4 \
src.ll -o o3.ll

opt -S '-passes=default' --vectorize-slp=false \
-mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64-v4 \
src.ll -o o3-no-slp.ll

llc -O2 -mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64-v4 \
src.ll -o raw.s
llc -O2 -mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64-v4 \
o3.ll -o o3.s
llc -O2 -mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64-v4 \
o3-no-slp.ll -o o3-no-slp.s

sed '/^[[:space:]]*retq[[:space:]]*$/d' input.s | \
llvm-mca --mtriple=x86_64-unknown-linux-gnu --mcpu=x86-64-v4 \
--iterations=100
```

The SLP form has fewer instructions, and its simulated Total Cycles are lower
than direct raw lowering, so I am not claiming that this alone proves a
wall-clock regression. However, it has worse modeled Block RThroughput than
both the original and the O3-no-SLP form, and O3-no-SLP also has substantially
fewer Total Cycles.

Why is this vectorization considered profitable? Does the SLP cost model
under-account for the shuffle/horizontal-reduction resource pressure in this
x86 lowering, or is Block RThroughput not relevant to this decision?

Related to #201107.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.