[SPIRV] add pre legalization instruction combine (#122839)

- Add the boilerplate to support instcombine in SPIRV
- instcombine length(X-Y) to distance(X,Y)
- switch HLSL's distance intrinsic to no

[SPIRV] add pre legalization instruction combine (#122839)

- Add the boilerplate to support instcombine in SPIRV
- instcombine length(X-Y) to distance(X,Y)
- switch HLSL's distance intrinsic to not special case for SPIRV.
- fixes #122766
- This RFC we were requested to add in the infra for pattern matching:
https://discourse.llvm.org/t/rfc-add-targetbuiltins-for-spirv-to-support-hlsl/83329/13

show more ...

[SPIR-V] Overhaul module analysis to improve translation speed and simplify the underlying logics (#120415)

This PR is to address legacy issues with module analysis that currently
uses a complicate

[SPIR-V] Overhaul module analysis to improve translation speed and simplify the underlying logics (#120415)

This PR is to address legacy issues with module analysis that currently
uses a complicated and not so efficient approach to trace dependencies
between SPIR-V id's via a duplicate tracker data structures and an
explicitly built dependency graph. Even a quick performance check
without any specialized benchmarks points to this part of the
implementation as a biggest bottleneck.

This PR specifically:
* eliminates a need to build a dependency graph as a data structure,
* updates the test suite (mainly, by fixing incorrect CHECK's referring
to a hardcoded order of definitions, contradicting the spec requirement
to allow certain definitions to go "in any order", see
https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_logical_layout_of_a_module),
* improves function pointers implementation so that it now passes
EXPENSIVE_CHECKS (thus removing 3 XFAIL's in the test suite).

As a quick sanity check of whether goals of the PR are achieved, we can
measure time of translation for any big LLVM IR. While testing the PR in
the local development environment, improvements of the x5 order have
been observed.

For example, the SYCL test case "group barrier" that is a ~1Mb binary IR
input shows the following values of the naive performance metric that we
can nevertheless apply here to roughly estimate effects of the PR.

before the PR:
```
$ time llc -O0 -mtriple=spirv64v1.6-unknown-unknown _group_barrier_phi.bc -o 1 --filetype=obj

real 3m33.241s
user 3m14.688s
sys 0m18.530s
```

after the PR

```
$ time llc -O0 -mtriple=spirv64v1.6-unknown-unknown _group_barrier_phi.bc -o 1 --filetype=obj

real 0m42.031s
user 0m38.834s
sys 0m3.193s
```

Next work should probably address Duplicate Tracker further, as it needs
analysis now from the perspective of what parts of it are not necessary
now, after changing the approach to implementation of the module
analysis step.

show more ...

[SPIR-V] Add saturation and float rounding mode decorations, a subset of arithmetic constrained floating-point intrinsics, and SPV_INTEL_float_controls2 extension (#119862)

This PR adds the followin

[SPIR-V] Add saturation and float rounding mode decorations, a subset of arithmetic constrained floating-point intrinsics, and SPV_INTEL_float_controls2 extension (#119862)

This PR adds the following features:
* saturation and float rounding mode decorations,
* arithmetic constrained floating-point intrinsics (strict_fadd,
strict_fsub, strict_fmul, strict_fdiv, strict_frem, strict_fma and
strict_fldexp),
* and SPV_INTEL_float_controls2 extension,
* using recent improvements of emit-intrinsics step, this PR also
simplifies pre- and post-legalizer steps and improves instruction
selection.

show more ...

[SPIR-V] Improve general validity of emitted code between passes (#119202)

This PR improves general validity of emitted code between passes due to
generation of `TargetOpcode::PHI` instead of `SPIR

[SPIR-V] Improve general validity of emitted code between passes (#119202)

This PR improves general validity of emitted code between passes due to
generation of `TargetOpcode::PHI` instead of `SPIRV::OpPhi` after
Instruction Selection, fixing generation of OpTypePointer instructions
and using of proper virtual register classes.

Using `TargetOpcode::PHI` instead of `SPIRV::OpPhi` after Instruction
Selection has a benefit to support existing optimization passes
immediately, as an alternative path to disable those passes that use
`MI.isPHI()`. This PR makes it possible thus to revert
https://github.com/llvm/llvm-project/pull/116060 actions and get back to
use the `MachineSink` pass.

This PR is a solution of the problem discussed in details in
https://github.com/llvm/llvm-project/pull/110507. It accepts an advice
from code reviewers of the PR #110507 to postpone generation of OpPhi
rather than to patch CodeGen. This solution allows to unblock
improvements wrt. expensive checks and makes it unrelated to the general
points of the discussion about OpPhi vs. G_PHI/PHI.

This PR contains numerous small patches of emitted code validity that
allows to substantially pass rate with expensive checks. Namely, the
test suite with expensive checks set ON now has only 12 fails out of 569
total test cases.

FYI @bogner

show more ...

[SPIR-V] No OpBitcast is generated for a bitcast between identical types (#114877)

The goal of the PR is to ensure that no OpBitcast is generated for a
bitcast between identical types.

This PR r

[SPIR-V] No OpBitcast is generated for a bitcast between identical types (#114877)

The goal of the PR is to ensure that no OpBitcast is generated for a
bitcast between identical types.

This PR resolves https://github.com/llvm/llvm-project/issues/114482

show more ...

[SPIR-V] Fix OpDecorate emission after vreg def. (#114426)

In SPIR-V, OpDecorate instructions are allowed to forward-declare a
virtual register. But while we are at the MIR level, we must comply wi

[SPIR-V] Fix OpDecorate emission after vreg def. (#114426)

In SPIR-V, OpDecorate instructions are allowed to forward-declare a
virtual register. But while we are at the MIR level, we must comply with
stricter rules, meaning OpDecorate should be emited after, not before
the reg definition.
(In some cases, we defined those just before, switching to just after).

Related to #110652

---------

Signed-off-by: Nathan Gauër <brioche@google.com>

show more ...

[SPIR-V] Do instruction selection for G_BITCAST on an earlier stage (#114216)

This PR implements instruction selection for G_BITCAST on an earlier
stage to avoid MachineVerifier complains on subtle

[SPIR-V] Do instruction selection for G_BITCAST on an earlier stage (#114216)

This PR implements instruction selection for G_BITCAST on an earlier
stage to avoid MachineVerifier complains on subtle semantics difference
between G_BITCAST and OpBitcast.

We do instruction selections for OpBitcast after IR Translation instead
of calling MIB.buildBitcast() generating the general op code G_BITCAST,
because when MachineVerifier validates G_BITCAST we see a check of a
kind: 'if Source Type is equal to Destination Type then report error
"bitcast must change the type"'. This doesn't take into account the
notion of a typed pointer that is important for SPIR-V where a user may
and should use bitcast between pointers with different pointee types
(https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpBitcast).

It's important for correct lowering in SPIR-V, because interpretation of
the data type is not left to instructions that utilize the pointer, but
encoded by the pointer declaration, and the SPIRV target can and must
handle the declaration and use of pointers that specify the type of data
they point to.

It's not feasible to improve validation of G_BITCAST using just
information provided by low level types of source and destination.
Therefore we don't produce G_BITCAST as the general op code with
semantics different from OpBitcast, but rather lower to OpBitcast
immediately.

See discussion in https://github.com/llvm/llvm-project/pull/110270 for
even more context.

show more ...

[SPIR-V] Implement OpSpecConstantOp with ptr-cast operation (#109979)

This PR reworks implementation of OpSpecConstantOp with ptr-cast
operation (PtrCastToGeneric, GenericCastToPtr). Previous imple

[SPIR-V] Implement OpSpecConstantOp with ptr-cast operation (#109979)

This PR reworks implementation of OpSpecConstantOp with ptr-cast
operation (PtrCastToGeneric, GenericCastToPtr). Previous implementation
didn't take into account a lot of use cases, including multiple
inclusion of pointers, reference to a pointer from OpName, etc. A
reproducer is attached as a new test case.

This PR also fixes wrong type inference for IR patterns which generate
new virtual registers without SPIRV type. Previous implementation
assumed always that result has the same address space as a source that
is not the fact, and, for example, led to impossibility to emit a
ptr-cast operation in the reproducer, because wrong type inference
rendered source and destination with the same address space, eliminating
translation of G_ADDRSPACE_CAST.

show more ...

[SPIR-V] Fix inconsistency between previously deduced element type of a pointer and function's return type (#109660)

This PR improves type inference and fixes inconsistency between
previously deduc

[SPIR-V] Fix inconsistency between previously deduced element type of a pointer and function's return type (#109660)

This PR improves type inference and fixes inconsistency between
previously deduced element type of a pointer and function's return type.
It fixes https://github.com/llvm/llvm-project/issues/109401 by ensuring
that OpPhi is consistent with respect to operand types.

show more ...

[SPIR-V] Allow intrinsics with aggregate return type to reach GlobalISel (#108893)

Two main goals of this PR are:
* to support "Arithmetic with Overflow" intrinsics, including the
special case whe

[SPIR-V] Allow intrinsics with aggregate return type to reach GlobalISel (#108893)

Two main goals of this PR are:
* to support "Arithmetic with Overflow" intrinsics, including the
special case when those intrinsics are being generated by the
CodeGenPrepare pass during translations with optimization;
* to redirect intrinsics with aggregate return type to be lowered via
GlobalISel operations instead of SPIRV-specific unfolding/lowering (see
https://github.com/llvm/llvm-project/pull/95012).

There is a new test case
`llvm/test/CodeGen/SPIRV/passes/translate-aggregate-uaddo.ll` that
describes and checks the general logics of the translation.

This PR continues a series of PRs aimed to identify and fix flaws in
code emission, to improve pass rates for the mode with expensive checks
set on (see https://github.com/llvm/llvm-project/pull/101732,
https://github.com/llvm/llvm-project/pull/104104,
https://github.com/llvm/llvm-project/pull/106966), having in mind the
ultimate goal of proceeding towards the non-experimental status of
SPIR-V Backend.

The reproducers are:

1) consider `llc -O3 -mtriple=spirv64-unknown-unknown ...` with:

```
define spir_func i32 @foo(i32 %a, ptr addrspace(4) %p) {
entry:
br label %l1

l1:
%e = phi i32 [ %a, %entry ], [ %i, %body ]
%i = add nsw i32 %e, 1
%fl = icmp eq i32 %i, 0
br i1 %fl, label %exit, label %body

body:
store i8 42, ptr addrspace(4) %p
br label %l1

exit:
ret i32 %i
}
```

2) consider `llc -O0 -mtriple=spirv64-unknown-unknown ...` with:

```
define spir_func i32 @foo(i32 %a, ptr addrspace(4) %p) {
entry:
br label %l1

l1: ; preds = %body, %entry
%e = phi i32 [ %a, %entry ], [ %math, %body ]
%0 = call { i32, i1 } @llvm.uadd.with.overflow.i32(i32 %e, i32 1)
%math = extractvalue { i32, i1 } %0, 0
%ov = extractvalue { i32, i1 } %0, 1
br i1 %ov, label %exit, label %body

body: ; preds = %l1
store i8 42, ptr addrspace(4) %p, align 1
br label %l1

exit: ; preds = %l1
ret i32 %math
}
```

show more ...

[SPIR-V] Fix bad insertion for type/id MIR (#109686)

Those instructions were inserted either after the instruction using it,
or in the middle of the module.
The first directly causes an issue. The

[SPIR-V] Fix bad insertion for type/id MIR (#109686)

Those instructions were inserted either after the instruction using it,
or in the middle of the module.
The first directly causes an issue. The second causes a more subtle
issue: the first type the type is inserted, the emission is fine, but
the second times, the first instruction is reused, without checking its
position in the function. This can lead to the second usage dominating
the definition.

In SPIR-V, types are usually in the header, above all code definition,
but at this stage I don't think we can, so what I do instead is to emit
it in the first basic block.

This commit reduces the failed tests with expensive checks from 107 to
71.

Signed-off-by: Nathan Gauër <brioche@google.com>

show more ...

[SPIR-V] Add SPIR-V structurizer (#107408)

This commit adds an initial SPIR-V structurizer.
It leverages the previously merged passes, and the convergence region
analysis to determine the correct

[SPIR-V] Add SPIR-V structurizer (#107408)

This commit adds an initial SPIR-V structurizer.
It leverages the previously merged passes, and the convergence region
analysis to determine the correct merge and continue blocks for SPIR-V.

The first part does a branch cleanup (simplifying switches, and
legalizing them), then merge instructions are added to cycles,
convergent and later divergent blocks.
Then comes the important part: splitting critical edges, and making sure
the divergent construct boundaries don't cross.

- we split blocks with multiple headers into 2 blocks.
- we split blocks that are a merge blocks for 2 or more constructs:
SPIR-V spec disallow a merge block to be shared by 2
loop/switch/condition construct.
- we split merge & continue blocks: SPIR-V spec disallow a basic block
to be both a continue block, and a merge block.
- we remove superfluous headers: when a header doesn't bring more info
than the parent on the divergence state, it must be removed.

This PR leverages the merged SPIR-V simulator for testing, as long as
spirv-val. For now, most DXC structurization tests are passing. The
unsupported ones are either caused by unsupported features like switches
on boolean types, or switches in region exits, because the MergeExit
pass doesn't support those yet (there is a FIXME).

This PR is quite large, and the addition not trivial, so I tried to keep
it simple. E.G: as soon as the CFG changes, I recompute the dominator
trees and other structures instead of updating them.

---------

Signed-off-by: Nathan Gauër <brioche@google.com>

show more ...

[SPIR-V] Improve correctness of emitted MIR between passes for branching instructions (#106966)

This PR improves correctness of emitted MIR between passes for branching
instructions and thus increa

[SPIR-V] Improve correctness of emitted MIR between passes for branching instructions (#106966)

This PR improves correctness of emitted MIR between passes for branching
instructions and thus increase number of passing tests when expensive
checks are on. Specifically, we address here such issues with machine
verifier as:
* fix switch generation: generate correct successors and undo the
"address taken" status to reflect that a successor doesn't actually
correspond to an IR-level basic block;
* fix incorrect definition of OpBranch and OpBranchConditional in
TableGen (SPIRVInstrInfo.td) to set isBarrier status properly and set a
correct type of virtual registers;
* fix a case when Phi refers to a type definition that goes after the
Phi instruction, so that the virtual register definition of the type
doesn't dominate all uses.

This PR decrease number of failing tests under expensive checks from 56
to 50.

show more ...

[SPIR-V] Rework usage of virtual registers' types and classes (#104104)

This PR continues https://github.com/llvm/llvm-project/pull/101732
changes in virtual register processing aimed to improve co

[SPIR-V] Rework usage of virtual registers' types and classes (#104104)

This PR continues https://github.com/llvm/llvm-project/pull/101732
changes in virtual register processing aimed to improve correctness of
emitted MIR between passes from the perspective of MachineVerifier.
Namely, the following changes are introduced:
* register classes (lib/Target/SPIRV/SPIRVRegisterInfo.td) and
instruction patterns (lib/Target/SPIRV/SPIRVInstrInfo.td) are corrected
and simplified (by removing unnecessary sophisticated options) -- e.g.,
this PR gets rid of duplicating 32/64 bits patterns, removes ANYID
register class and simplifies definition of the rest of register
classes,
* hardcoded LLT scalar types in passes before instruction selection are
corrected -- the goal is to have correct bit width before instruction
selection, and use 64 bits registers for pattern matching in the
instruction selection pass; 32-bit registers remain where they are
described in such terms by SPIR-V specification (like, for example,
creation of virtual registers for scope/mem semantics operands),
* rework virtual register type/class assignment for calls/builtins
lowering,
* a series of minor changes to fix validity of emitted code between
passes:
- ensure that that bitcast changes the type,
- fix the pattern for instruction selection for OpExtInst,
- simplify inline asm operands usage,
- account for arbitrary integer sizes / update legalizer rules;
* add '-verify-machineinstrs' to existed test cases.

See also https://github.com/llvm/llvm-project/issues/88129 that this PR
may resolve.

This PR fixes a great number of issues reported by MachineVerifier and,
as a result, reduces a number of failed test cases for the mode with
expensive checks set on from ~200 to ~57.

show more ...

[SPIR-V] Add implementation of the non-const G_BUILD_VECTOR and fix emission of the OpGroupBroadcast instruction (#103050)

This PR addresses a TODO in
lib/Target/SPIRV/SPIRVInstructionSelector.cpp

[SPIR-V] Add implementation of the non-const G_BUILD_VECTOR and fix emission of the OpGroupBroadcast instruction (#103050)

This PR addresses a TODO in
lib/Target/SPIRV/SPIRVInstructionSelector.cpp by adding implementation
of the non-const G_BUILD_VECTOR, and fix emission of the
OpGroupBroadcast instruction for the case when the `..._group_broadcast`
builtin has more than one `local_id` argument and `OpGroupBroadcast`
requires a newly constructed vector with 2 or 3 components instead of
originally passed series of `local_id` arguments.

This PR may resolve https://github.com/llvm/llvm-project/issues/97310 if
the reason for the reported fail is an incorrectly generated
OpGroupBroadcast instruction that was definitely a case.

Existing test is hardened and a new test is added to cover this special
case of the OpGroupBroadcast instruction emission.

show more ...

[SPIR-V] Rework usage of virtual registers' types and classes (#101732)

This PR contains changes in virtual register processing aimed to improve
correctness of emitted MIR between passes from the p

[SPIR-V] Rework usage of virtual registers' types and classes (#101732)

This PR contains changes in virtual register processing aimed to improve
correctness of emitted MIR between passes from the perspective of
MachineVerifier. This potentially helps to detect previously missed
flaws in code emission and harden the test suite. As a measure of
correctness and usefulness of this PR we may use a mode with expensive
checks set on, and MachineVerifier reports problems in the test suite.

In order to satisfy Machine Verifier requirements to MIR correctness not
only a rework of usage of virtual registers' types and classes is
required, but also corrections into pre-legalizer and instruction
selection logics. Namely, the following changes are introduced:
* scalar virtual registers have proper bit width,
* detect register class by SPIR-V type,
* add a superclass for id virtual register classes,
* fix Tablegen rules used for instruction selection,
* fixes of minor existed issues (missed flag for proper representation
of a null constant for OpenCL vs. HLSL, wrong usage of integer virtual
registers as a synonym of any non-type virtual register).

show more ...

[SPIRV] Improve type inference of operand presented by opaque pointers and aggregate types (#98035)

This PR improves type inference of operand presented by opaque pointers
and aggregate types:
* t

[SPIRV] Improve type inference of operand presented by opaque pointers and aggregate types (#98035)

This PR improves type inference of operand presented by opaque pointers
and aggregate types:
* tries to restore original function return type for aggregate types so
that it's possible to deduce a correct type during emit-intrinsics step
(see llvm/test/CodeGen/SPIRV/SpecConstants/restore-spec-type.ll for the
reproducer of the previously existed issue when spirv-val found a
mismatch between object and ptr types in OpStore due to the incorrect
aggregate types tracing),
* explores untyped pointer operands of store to deduce correct pointee
types,
* creates an extension type to track pointee types from emit-intrinsics
step and further instead of direct and naive usage of TypePointerType
that led previously to crashes due to ban of creation of Value of
TypePointerType type,
* tracks instructions with uncomplete type information and tries to
improve their type info after pass calculated types for all machine
functions (it doesn't traverse a code but rather checks only those
instructions which were tracked as uncompleted),
* address more cases of removing unnecessary bitcasts (see, for example,
changes in test/CodeGen/SPIRV/transcoding/OpGenericCastToPtr.ll where
`CHECK-SPIRV-NEXT` in LIT checks show absence of unneeded bitcasts and
unmangled/mangled versions have proper typing now with equivalent type
info),
* address more cases of well known types or relations between types
within instructions (see, for example, atomic*.ll test cases and
Event-related test cases for improved SPIR-V code generated by the
Backend),
* fix the issue of removing unneeded ptrcast instructions in
pre-legalizer pass that led to creation of new assign-type instructions
with the same argument as source in ptrcast and caused errors in type
inference (the reproducer `complex.ll` test case is added to the PR).

show more ...

[SPIR-V] Improve pattern matching and tracking of constant integers (#96615)

This PR fixes the issue
https://github.com/llvm/llvm-project/issues/96614 by improve pattern
matching and tracking of c

[SPIR-V] Improve pattern matching and tracking of constant integers (#96615)

This PR fixes the issue
https://github.com/llvm/llvm-project/issues/96614 by improve pattern
matching and tracking of constant integers. The attached test is
successful if it doesn't crash and generate valid SPIR-V code for both
32 and 64 bits targets.

show more ...

[SPIR-V] Ensure that cleaning of temporary constants doesn't purge tracked constants (#95303)

This PR fixes a problem in logics of cleaning unused constants, ensuring
that cleaning of temporary con

[SPIR-V] Ensure that cleaning of temporary constants doesn't purge tracked constants (#95303)

This PR fixes a problem in logics of cleaning unused constants, ensuring
that cleaning of temporary constants doesn't purge tracked constants. On
a rare occasion when this happens SPIR-V Backend emits a code that
refers to a non-existent register, earlier related with a constant.
Attached to the PR test case is a minimal reproducer where names of
variables and instructions lead to such a rare coincidence.

show more ...

[SPIR-V] Validate and fix bit width of scalar registers (#95147)

This PR improves legalization process of SPIR-V instructions. Namely, it
introduces validation and fixing of bit width of scalar reg

[SPIR-V] Validate and fix bit width of scalar registers (#95147)

This PR improves legalization process of SPIR-V instructions. Namely, it
introduces validation and fixing of bit width of scalar registers as a
part of pre-legalizer. A test case is added that demonstrates ability to
legalize instructions with non 8/16/32/64 bit width both with and
without vendor-specific SPIR-V extension
(SPV_INTEL_arbitrary_precision_integers). In the case of absence of the
extension, a generated SPIR-V code will fallback to 8/16/32/64 bit width
in OpTypeInt, but SPIR-V Backend still is able to legalize operations
with original integer sizes.

show more ...

[SPIR-V] Improve type inference, addrspacecast and dependencies between SPIR-V entities and required capability/extensions (#94626)

This PR continues https://github.com/llvm/llvm-project/pull/94467

[SPIR-V] Improve type inference, addrspacecast and dependencies between SPIR-V entities and required capability/extensions (#94626)

This PR continues https://github.com/llvm/llvm-project/pull/94467 and
contains fixes in emission of type intrinsics, constant recording and
corresponding test cases:
* type-deduce-global-dup.ll -- fix of integer constant emission on
32-bit platforms and correct type deduction for globals
* type-deduce-simple-for.ll -- fix of GEP translation (there was an
issue previously that led to incorrect translation/broken logic of
for-range implementation)

This PR also:
* fixes a cast between identical storage classes and updates the test
case to include validation run by spirv-val,
* ensures that Bitcast for pointers satisfies the requirement that the
address spaces must match and adds the corresponding test case,
* improve encode in Tablegen and decode in code of dependencies between
SPIR-V entities and required capability/extensions,
* prevent emission of identical OpTypePointer instructions.

show more ...

[SPIR-V] Add validation to the test case with get_image_array_size/get_image_dim calls (#94467)

This PR is to add validation to the test case with
get_image_array_size/get_image_dim calls
(transco

[SPIR-V] Add validation to the test case with get_image_array_size/get_image_dim calls (#94467)

This PR is to add validation to the test case with
get_image_array_size/get_image_dim calls
(transcoding/check_ro_qualifier.ll). This test case didn't pass
validation because of invalid emission of OpCompositeExtract instruction
(Result Type must be the same type as Composite.).

In order to fix the problem this PR improves type inference in general
and partially addresses issues:
* https://github.com/llvm/llvm-project/issues/91998
* https://github.com/llvm/llvm-project/issues/91997

A reproducer from the description of the latter issue is added as a new
test case as a part of this PR.

show more ...

[SPIR-V] Fix legalize info for G_BITREVERSE (#93699)

This PR fixes legalize info for G_BITREVERSE.

[SPIR-V] Implement correct zeroinitializer for extension types in SPIR-V Backend (#93607)

This PR implements correct zeroinitializer for extension types in SPIR-V
Backend.

Previous version has j

[SPIR-V] Implement correct zeroinitializer for extension types in SPIR-V Backend (#93607)

This PR implements correct zeroinitializer for extension types in SPIR-V
Backend.

Previous version has just created 0 of 32/64 integer type (depending on
target machine word size), that caused re-use and type re-write of the
corresponding integer constant 0 with a potential crash on wrong usage
of the constant (i.e., 0 of integer type expected but extension type
found). E.g., the following code would crash without the PR:

```
%r1 = icmp ne i64 %_arg_i, 0
%e1 = tail call spir_func target("spirv.Event") @__spirv_GroupAsyncCopy(i32 2, ptr addrspace(3) %_arg_local, ptr addrspace(1) %_arg_ptr, i64 1, i64 1, target("spirv.Event") zeroinitializer)
```

because 0 in icmp would eventually be of `Event` type.

show more ...

[SPIR-V] Inline assembly support (#93164)

This PR introduces support for inline assembly calls for SPIR-V Backend
in general, and support for SPV_INTEL_inline_assembly [1] extension in
particular.

[SPIR-V] Inline assembly support (#93164)

This PR introduces support for inline assembly calls for SPIR-V Backend
in general, and support for SPV_INTEL_inline_assembly [1] extension in
particular. The former part of the PR is agnostic towards
vendor-specific requirements and resolves the task of supporting
successful transformation of inline assembly as long as it's possible
without specific SPIR-V instruction codes.

As a part of the PR there appears an opportunity to bring coherent
inline assembly information up to latest passes of the transformation
process (emitting final SPIR-V instructions), so that PR makes it easy
to add any another required flavor of inline assembly, other then
supported by the vendor specific SPV_INTEL_inline_assembly extension,
if/when needed.

At the moment, however, SPV_INTEL_inline_assembly is the only
implemented way to bring LLVM IR inline assembly calls up to valid
SPIR-V instructions and also the default one. This means that inline
assembly calls will generate an error message of such extension is not
used to prevent LLVM-generated error messages at the final stages of
translation. When the SPV_INTEL_inline_assembly extension is mentioned
among supported, translation of inline assembly is intercepted by this
extension implementation on a pre-legalizer step, and this is a place
where support for a new inline assembly extension may be added if
needed.

This PR also extends support for register classes, improves type
inference during pre-legalizer pass, and fixes a minor bug with
asm-printing of string literals.

[1]
https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_inline_assembly.asciidoc

show more ...