alan-baker

If I understand correctly if you compile directly from the spirv-llvm-translator you end up `OpFMod` in the SPIR-V because the translator maps directly to the llvm instruction and clspv maps...

> Native math pass do not discard that much the unused libclc functios anymore. Since we link in lazy the module, we only get what we need from there. So...

> The OpFMod instruction is only an example. Maybe it is a bad example. I have deal with a fork of the clspv witch is somewhat outdated. But the idea...

Please rebase this and resolve the conflicts.

The shader looks ok to me. If you make the stores have thread dependent values (e.g. store `tid`) is the writing occurring in the right threads? I would guess driver...

I'll take a look, I would have thought this was handled already.

This issue was spawned from https://github.com/KhronosGroup/SPIRV-Tools/issues/1960. There is an unreachable selection that branches to a block that breaks from the loop. If the selection header had been reachable, CFG would...

The attachment in the description has a simplified version of the other bug. Reproducing here for simplicity: ``` #version 310 es void main() { if (true) { return; } else...

Can you try with `--decorate-nonuniform` and see if that fixes your problem? You'll need to enable the descriptor indexing features on the Vulkan side too (specifically `shaderStorageBufferArrayNonUniformIndexing` assuming these end...

It is a clspv issue, but since there might be a performance cost (and most cases don't need this) we don't enable it by default. Vulkan requires that non-uniform descriptor...