Here's a bizarre result...
I'm building a kernel with ioc64 along with the "-ir" and "-asm" options.
The kernel builds, loads and runs fine as an optimized binary or as source.
But I added the "-spirv64" option and ioc64 is emitting a SPIR-V file from a tiny kernel from last week.
Is there a directory that isn't being cleaned out somewhere?
So far I have not been able to replicate here. One possibility is that the SPIR-V compile is not completing. Is there a way you can send a reproducer so we can investigate? If there are any concerns about public posting please feel free to send a private message.
Every iocXX invocation correctly emits a proper .ir and .asm file but the various txt-spirXX and spirXX files are from the old kernel.
But here's a new data point.
I just tried creating a Code Builder session of the kernel that I'm working on and... it *correctly* generates the various SPIR files.
Now compilation of the kernel either from the command line with iocXX or VS2015 is emitting correct SPIR-V but I haven't tested to see if the emitted SPIR-V is always going to be a stale version of the kernel.
Summary: there is some unexplained interaction between VS Code Builder sessions and command-line iocXX.
Confirmed... iocXX returns whatever SPIRV or TXT-SPIRV kernels were last built by a Code Builder session.
So what's the culprit?
The culprit is supplying build options if you're trying to output some form of SPIR-V.
Splitting the build into an optimized IR/ASM build (with options) and a SPIR-V build (with no options at all other than maybe an include path) solved my problem.
$(BINS): foo.cl $(IOC) -cmd=build -bo="$(IOC_IR_OPTS)" -device=cpu_2_1 -simd=avx2 -input=foo.cl -ir -asm $(IOC) -cmd=build -device=cpu_2_1 -simd=avx2 -input=foo.cl -spirv64 -txt-spirv64
... where $(IOC_IR_OPTS) contains your standard "-cl-XXX" optimization options.
Please fix this since silently emitting the last successful SPIR-V build from some deep dark corner of my workstation is a super nasty bug.
Jeremy, I've attached a reproducer.
The summary is that if you're generating SPIR-V and including any build option other than "-cl-std=CL2.0" then an old SPIR-V result is emitted.
============================================== GOOD ============================================== $>make_good $>set BUILD_OPTS="-cl-std=CL2.0" $>ioc64 -cmd=build -bo="-cl-std=CL2.0" -device=cpu_2_1 -simd=avx2 -input=Noise2D.cl -spirv64=Noise2D.good.spv -txt-spirv64=Noise2D.good.spx $>ioc64 -cmd=build -bo="-cl-std=CL2.0" -device=cpu_2_1 -simd=avx2 -input=Noise3D.cl -spirv64=Noise3D.good.spv -txt-spirv64=Noise3D.good.spx $>diff -q Noise2D.good.spv Noise3D.good.spv Files Noise2D.good.spv and Noise3D.good.spv differ <---- AS EXPECTED, DIFFERENT KERNELS HAVE DIFFERENT OUTPUT $>diff -q Noise2D.good.spx Noise3D.good.spx Files Noise2D.good.spx and Noise3D.good.spx differ <---- AS EXPECTED, DIFFERENT KERNELS HAVE DIFFERENT OUTPUT ============================================== BAD ============================================== $>make_bad $>set BUILD_OPTS="-cl-std=CL2.0 -cl-fast-relaxed-math" $>ioc64 -cmd=build -bo="-cl-std=CL2.0 -cl-fast-relaxed-math" -device=cpu_2_1 -simd=avx2 -input=Noise2D.cl -spirv64=Noise2D.bad.spv -txt-spirv64=Noise2D.bad.spx $>ioc64 -cmd=build -bo="-cl-std=CL2.0 -cl-fast-relaxed-math" -device=cpu_2_1 -simd=avx2 -input=Noise3D.cl -spirv64=Noise3D.bad.spv -txt-spirv64=Noise3D.bad.spx $>diff -q Noise2D.bad.spv Noise3D.bad.spv <---- KERNEL OUTPUT IS SAME -- IOC64 IS SILENTLY FAILING SOMEWHERE $>diff -q Noise2D.bad.spx Noise3D.bad.spx <---- KERNEL OUTPUT IS SAME -- IOC64 IS SILENTLY FAILING SOMEWHERE