Compile and link flows lose compile options

[alan-baker]

When performing compile and link flows clspv is instructed to compile to IR. This skips the optimizations passes; however currently clspv needs to know several of those options to compile properly. For example, whether generic address space is used (and the requirement to inline). Linking programs are not expected to resupply those options. So those options are sort just lost in the process. This can lead to internal compiler errors in clspv. It probably doesn't make sense to try and optimize before generating IR, but there needs to be a way to include those options later. A worrisome case would be when different programs are linked that have different compile options.

[rjodinchr]

I think the compile options should be stored as metadata inside the LLVM IR. This is because a compiled program can be exported (clGetProgramInfo(..., CL_PROGRAM_BINARIES)). I don't think we want to make it more complicated in clvk and add a header to the LLVM IR. Adding the information as LLVM IR metadata should be enough.

So it would mean that the work is entirely on the clspv side.

Then for the different compile options. I wonder if we can make some rules on how to merge them:

• -D: Do not keep in the metadata, they have already been used by the frontend to get to the LLVM IR
• -I: Do not keep in the metadata, they have already been used by the frontend to get to the LLVM IR
• -cl-single-precision-constant: Keep only if all programs use it
• -cl-denorms-are-zero: Keep only if all programs use it
• -cl-fp32-correctly-rounded-divide-sqrt: ignored by clspv
• -cl-opt-disable: ignored by clspv
• -cl-uniform-work-group-size: not defined in clspv
• -cl-no-subgroup-ifp: not defined in clspv
• -cl-mad-enable: Keep only if all programs use it
• -cl-no-signed-zeros: ignored by clspv
• -cl-unsafe-math-optimizations: Keep only if all programs use it
• -cl-finite-math-only: Keep only if all programs use it
• -cl-fast-relaxed-math: Keep only if all programs use it
• -w: Do not keep in the metadata
• -Werror: Do not keep in the metadata
• -cl-std: Use the highest version
• -cl-kernel-arg-info: Enable if one program uses it
• -g: Enable if one program uses it

[alan-baker]

That could work, but I haven't investigated re-parsing the options in clspv once we've loaded all the modules. It would also be possible for clvk to store the user provided options in the cvk_program and we do the merging there. I'm not certain which is easier.

The merging rules seem reasonable. Hopefully there aren't many programs asking for some modules with fast math and some without.

[rjodinchr]

I've worked a bit on it, I think it is better to do it in clvk in the end. I am starting to implement it.

clspv re-parsing looks too complicated, and the worry I had about exporting the binaries in clvk looks manageable.