[SPIR-V] Intrinsics which are Termination Instructions fail Legalizations

[devshgraphicsprogramming]

Description

I added OpTerminateRayKHR with an inline SPIR-V intrinsic and put it in an if branch in place of AcceptHitAndEndSearch().

The shader fails to compile.

Steps to Reproduce

https://godbolt.org/z/sKWY1Kofa

[[vk::ext_capability(/*spv::CapabilityRayTracingKHR*/4479)]]
[[vk::ext_extension("SPV_KHR_ray_tracing")]]
[[vk::ext_instruction(/*spv::OpTerminateRayKHR*/4449)]]
void terminateRay();

struct [raypayload] OcclusionPayload
{
    float32_t attenuation : read(caller,anyhit,miss) : write(caller,anyhit,miss);
};

[shader("anyhit")]
void main(inout OcclusionPayload payload, in BuiltInTriangleIntersectionAttributes attribs)
{
    if (payload.attenuation<0.001)
        terminateRay();
    IgnoreHit();
}

Actual Behavior

Even with the -Vd option I see

fatal error: failed to optimize SPIR-V: terminator instruction outside basic block
note: please file a bug report on https://github.com/Microsoft/DirectXShaderCompiler/issues with source code if possible

Compiler returned: 5

Also -O0 -Vd doin't let me see the SPIR-V that DXC tries to emit in this case.

Looking at the regular codegen, I can see that DXC does something really weird to my payload, even though I access it only to read it, it OpStores it back at the end of each branch. This may be dislodging the termination instruction.

Environment

• DXC version: Godbolt trunk
• Host Operating System : Linux

[s-perron]

I don't think there is much we can do about this. There is no way for the compiler to know instruction generated is a block terminator. I think this would require an update to the spec to add something that will terminate.

Also, why don't you want to use AcceptHitAndEndSearch();? In your example, I could see wanting to avoid the write to payload because it is redudant, but that is better done as an optimization.

[devshgraphicsprogramming]

I don't think there is much we can do about this. There is no way for the compiler to know instruction generated is a block terminator. I think this would require an update to the spec to add something that will terminate.

why not require me to write the payload and not try to write it behind my back?

Also, why don't you want to use AcceptHitAndEndSearch();? In your example, I could see wanting to avoid the write to payload because it is redudant, but that is better done as an optimization.

W just like doing as much as we can in SPIR-V instead of HLSL intrinsics, because later extensions are easier to support (64bit image atomics, BDA atomics, ray query position fetch from AS, etc.) without having to wait on HLSL to get an "official" intrinsic for that.