cl_khr_il_program extension

[AlexDemydenko]

This extension has a conflict between two FrontEnd compilers

1. clspv FrontEnd for transformation from *.cl to LLVM-IL
2. SPIRV-LLVM-Translator for transformation from spirv to LLVM-IL

The problem is that SPIRV-LLVM-Translator produce some unuxpected/different cases that give different results between the two paths.
The paths

1. *.cl -> clspv -> HW-binary_v1
2. *.cl -> -> *.spv -> clspv -> HW-binary_v2

The HW-binary_v1 & HW-binary_v2 have differences that produce differ not only in performance but in results also.

For example kernel with the fmod() function:

1. The clspv contains the sources of the builtin function that used for compilation, and LLVM-IL has a description of fmod() as a function and the implementation of this function as well. The fmod() has two algorithms one is good and another is fast. The clspv uses a good one.
2. The external compiler can transform this function to an opFRem instruction, which is fully legal because this instruction is equivalent to the fmod() function. But in this case, this instruction, without any transformations, goes to the compute shader pipeline in the vulkan driver. And for this driver, it is allowed to use the FAST-version of the opFrem instruction in the case of a compute shader in the graphics pipeline.

There should be an entry-point or pass where the external IL from spirv must be transformed/synchronized to a working version for the clspv compiler.