iocXX -spirvXX keeps emitting old kernel

[allanmac1]

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?

Any tips?

[Jeffrey_M_Intel1]

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.

[allanmac1]

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.

[Jeffrey_M_Intel1]

Thanks for the additional details.  It will still be very helpful for us to have a reproducer kernel to help us find the root cause.

[allanmac1]

I understand, I can't provide one at this point.

[allanmac1]

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.

For example:

$(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.

[allanmac1]

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.

Example:

==============================================
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

[Jeffrey_M_Intel1]

Thanks for the excellent reproducer!  Bug is reproduced and filed.