| Issue |
181195
|
| Summary |
[InstSimplify] Miscompilation of non-uniform vector bitcast (<4 x i24> to <3 x i32>)
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
varev-dev
|
https://godbolt.org/z/f6zjscc94
https://alive2.llvm.org/ce/z/w-JFvy
```llvm
define <3 x i32> @test() {
%bc = bitcast <4 x i24> <i24 1, i24 256, i24 65536, i24 0> to <3 x i32>
ret <3 x i32> %bc
}
```
```bash
opt -passes=instsimplify minimal.ll -S -o -
```
ConstantFolding incorrectly folds a bitcast between <4 x i24> and <3 x i32>. The transformation assumes a 1:1 element mapping, which violates the bitwise representation requirement of a `bitcast`.
The total bit width of both vectors is equal (96 bits), the individual element sizes (24 bits and 32 bits) are not giving integer ratio. In such case, a bitcast should perform a full bit-reinterpretation, where bits from one source element are often divided between two destination elements.
According to the [LLVM LangRef](https://llvm.org/docs/LangRef.html#bitcast-to-instruction):
> The ‘bitcast’ instruction converts value to type ty2 without changing any bits.
**Expected result:**
All bits from the source vector are reinterpreted as a 96-bit value and then split into three 32-bit integers, resulting in:
```llvm
ret <3 x i32> splat (i32 1)
```
**Actual result:**
Each i32 value is created by shifting next i24 src value to right place depending on endianness, rest is filled by zeros.
```llvm
ret <3 x i32> <i32 1, i32 256, i32 65536>
```
**In Memory Layout Comparison (Little Endian):**
```
00 01 02 03 04 05 06 07 08 09 0A 0B - Address
-- -- -- -- -- -- -- -- -- -- -- --
01 00 00 00 01 00 00 00 01 00 00 00 - Source / Expected Output
01 00 00 00 00 01 00 00 00 00 01 00 - Actual Output
```
This also relates to #179626 (reversed case `<3 x i32> to <4 x i24>`, resulted in crash).
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
