diff options
| author | Fraser Cormack <fraser@codeplay.com> | 2021-10-21 15:21:38 +0100 |
|---|---|---|
| committer | Fraser Cormack <fraser@codeplay.com> | 2021-10-21 17:10:08 +0100 |
| commit | 92673fad66f449f63acc76dfbb5e0bf05978663b (patch) | |
| tree | f9e898b62332569a70376e7474dad235b65fdc61 /clang/lib/Interpreter/Interpreter.cpp | |
| parent | baea663a6e9bc52f80995d02bb8149934c825612 (diff) | |
| download | llvm-92673fad66f449f63acc76dfbb5e0bf05978663b.zip llvm-92673fad66f449f63acc76dfbb5e0bf05978663b.tar.gz llvm-92673fad66f449f63acc76dfbb5e0bf05978663b.tar.bz2 | |
[RISCV] Add a test showing incorrect VSETVLI insertion
This test case, reduced from an internal test failure, shows how we may
incorrectly skip the insertion of VSETVLI instructions when doing
cross-basic-block analysis.
The entry block ends in a `e32,mf2`. Its single successor, %bb.1, ends with a
`e8,mf8`, but for a mask-type instruction, so is considered compatible.
This means that the info %bb.1 is merged into its predecessor so
produces a `e32,mf2`. When it comes to the last block, which requires a
`e32,mf2`, we skip the insertion of a vsetvli because all predecessors
were determined to preserve the right vtype.
However, when %bb.1 is actually laid out it does actually need a
`e8,mf8` vsetvli, since the previous instruction has a different tail
policy. This means that when execution flows from %bb.1 to %bb.3, the
`vadd.vx` is misconfigured.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112223
Diffstat (limited to 'clang/lib/Interpreter/Interpreter.cpp')
0 files changed, 0 insertions, 0 deletions