Add Intel specific definitions from https://github.com/KhronosGroup/S…

[MrSidims]

…PIRV-LLVM-Translator

List of extensions:
SPV_INTEL_fpga_memory_attributes
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_memory_attributes.asciidoc

SPV_INTEL_kernel_attributes
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_kernel_attributes.asciidoc

SPV_INTEL_fpga_reg
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_reg.asciidoc

SPV_INTEL_blocking_pipes
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_blocking_pipes.asciidoc

SPV_INTEL_fpga_loop_controls
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_fpga_loop_controls.asciidoc

SPV_INTEL_unstructured_loop_controls
https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/INTEL/SPV_INTEL_unstructured_loop_controls.asciidoc

Signed-off-by: Dmitry Sidorov [email protected]

[CLAassistant]

All committers have signed the CLA.

[MrSidims]

There are several definitions, that are not presenting in spirv.core.grammar.json, like RayFlagsShift which were removed after headers generation. Was it to be expected?

[johnkslang]

I'm concerned about continuing to create gaps here. See issue #151. I think you have all the intervening consecutive opcodes reserved.

[MrSidims]

The gaps will be partially filled when https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/SPIRV/SPV_INTEL_function_pointers.asciidoc and https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/SPIRV/SPV_INTEL_inline_assembly.asciidoc are published here.

[MrSidims]

Nevermind, this particular gap won't be filled by these extensions.

[MrSidims]

Left only json changes excluding generated headers.

[johnkslang]

Could you revisit this? Look at avoiding gaps (there was a comment about that), resolve conflicts. Did you want me to generated the headers?

[MrSidims]

Could you revisit this? Look at avoiding gaps (there was a comment about that), resolve conflicts. Did you want me to generated the headers?

I'll take a look what can be done to avoid the gaps now. The problem here is that the values present in https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/lib/SPIRV/libSPIRV/spirv.hpp as is.

Regarding the headers generation - I can do it myself, was just a little bit confused, that several definitions disappeared, see my comment from above.

[johnkslang]

I just rebuilt headers from your other commit, a few minutes ago. It all seemed consistent and okay.

It is okay if I build headers.

One thing we want to do is reuse enumerant values (from other enums) for the opcodes. If you have any reserved that have been used for other enums, feel free to reuse them for instructions also.

[MrSidims]

Got it. Currently we are filling the op codes interval from 5568 to 5631 with following extensions:
intel/llvm#1593
intel/llvm#1611
intel/llvm#1612

will come to the mentioned in this PR gap in the future.

[johnkslang]

Seems a couple things need to be fixed.

[johnkslang]

It seems this created two OpSubgroupAvcSicGetInterRawSadsINTEL. Is one supposed to be an alias, or we can have just one?

[MrSidims]

I suppose it's an artifact appeared after rebase, removed.

[johnkslang]

We want to keep these in numerical order.

[MrSidims]

Oops, thanks!

[MrSidims]

BTW, what are the rules for updating PRs in this repository? Shall fixes be amended into the original commit before updating, or it's OK to have commits, like: "Apply suggestions" and this commits will be squashed during the merge?

[johnkslang]

Something like this should go into the repo as a single commit. I'll squash when I remember. It is sometimes important to see feedback addressed as a separate commit, just for efficiency, but better to not have that jitter in master history.

Force pushing the PR is okay, when you want to control how the actual history will look.

This one is okay as it is now.