alan-baker

I have a local hack that undoes this in certain circumstances. That makes the CTS pass, but this is likely uncovering a bug where we are generating the wrong addressing...

Clspv will generate invalid SPIR-V some cases due to this issue. Take `test/Coherent/frexp.cl` for example. When compiled with `-cl-native-math` the resulting SPIR-V generates the following validation error: ``` error: line...

Thinking more about a general solution I think clspv needs to distinguish between the two needs for type inference: 1. Data type of a particular instruction 2. Data type of...

> #1306 has an interesting line here: https://github.com/google/clspv/pull/1306/files#diff-d82932682c3cce860c8c728b57e2a68e6b04593c1edb206934c340665fb71f29L16 > > ``` > kernel void bar(global int *A, global int *B, int n) { apple(A + 1, B, n); } >...

This is breaking some tests. Clspv currently assumes that it should be told which CL3.0 features ought to be enabled. If you instead request via the `--enable-feature-macros` command line option...

Clspv is only intended to produce SPIR-V that is valid in a Vulkan environment.

This is tricky. Our fake pointer casting doesn't work with atomics. So we'd have to prefer the uint type for inference. That's a reasonably large change. This isn't the only...

I generally prefer to have as few deviations from clang as possible. If anything I'd rather expose an option that can be forwarded to clang to let the user control...

Vulkan specifies the difference with more clarity: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#shaders-derivative-operations.

#4540 is tracking the only remaining work, recommend closing this issue.