[all-commits] [llvm/llvm-project] 6d4fb3: [SPIR-V] Emit valid SPIR-V code for integer sizes ...

[Vyacheslav Levytskyy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6d4fb3d3bbecbdfa1c98da3f7e09322abaec5f97
      https://github.com/llvm/llvm-project/commit/6d4fb3d3bbecbdfa1c98da3f7e09322abaec5f97
  Author: Vyacheslav Levytskyy <vyacheslav.levytskyy at intel.com>
  Date:   2024-06-05 (Wed, 05 Jun 2024)

  Changed paths:
    M llvm/lib/Target/SPIRV/SPIRVGlobalRegistry.cpp
    M llvm/lib/Target/SPIRV/SPIRVGlobalRegistry.h
    A llvm/test/CodeGen/SPIRV/no-i8-type-duplication.ll
    A llvm/test/CodeGen/SPIRV/transcoding/OpBitReverse-subbyte.ll
    M llvm/test/CodeGen/SPIRV/transcoding/OpBitReverse_i2.ll

  Log Message:
  -----------
  [SPIR-V] Emit valid SPIR-V code for integer sizes other than 8,16,32,64 (#94219)

Only with SPV_INTEL_arbitrary_precision_integers SPIR-V Backend creates
arbitrary sized integer types (<= 64 bits). Without such extension and
according to the SPIR-V specification
`SPIRVGlobalRegistry::getOpTypeInt()` rounds integer sizes other than
8,16,32,64 up, to one of defined by the specification sizes. For the
`DuplicateTracker` class this means that several original LLVM types
(e.g., i2, i4) map to the same "OpTypeInt 8" instruction. This breaks
`DuplicateTracker`'s logic and leads to generation of invalid SPIR-V
code eventually.

For example,

```
define spir_func void @foo(i2 %a, i4 %b) {
entry:
  %res2 = tail call i2 @llvm.bitreverse.i2(i2 %a)
  %res4 = tail call i4 @llvm.bitreverse.i4(i4 %b)
  ret void
}

declare i2 @llvm.bitreverse.i2(i2)
declare i4 @llvm.bitreverse.i4(i4)
```

after translation to SPIR-V would fail during validation (`spirv-val`)
due to two `OpTypeInt 8 0` instructions.

This PR fixes the issue by changing source LLVM type according to the
SPIR-V type that will be used in the emitted code.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications