spirv-val: Add SPV_ARM_core_builtins validation

[kpet]

Signed-off-by: Kevin Petit kevin.petit@arm.com
Change-Id: If1680a823aea9662d44def1ec6fe6ac334c00574

[dneto0]

Thanks!

[jeremy-lunarg]

Does this need a dependency bump? I'm seeing compilation errors. e.g.

/home/jeremy/Development/Vulkan/Khronos/SPIRV-Tools/source/val/validate_builtins.cpp:4228:10: error: ‘SpvBuiltInCoreIDARM’ was not declared in this scope
     case SpvBuiltInCoreIDARM:

[kpet]

Yes, it does. I've created #4962. This change should never have gone in as is. A few thoughts on what went wrong:

• This PR passed the CI which shouldn't have happened. I'm guessing the CI doesn't use the revisions from DEPS.
• git-sync-deps clones the headers into external/spirv-headers and was checking out the correct revision but I also had a copy under external/SPIRV-Headers where my changes were. When an external path to the headers is not provided via SPIRV-Headers_SOURCE_DIR the build system tries to use external/SPIRV-Headers or external/spirv-headers in that order. In my local testing, I was calling git-sync-deps and then building and running tests but the headers checked out by git-sync-deps were never used.

A couple of proposed improvements:

• Swap the search order for the default paths to the headers in the build system such that the path where git-sync-deps checks out the headers is favoured (see Align git-sync-deps and CMake to use external/spirv-headers by default #4963). Alternatively, the path used by git-sync-deps could be changed.
• Fix the CI so the revisions used all come from DEPS. Does this need an issue?

[s-perron]

Fix the CI so the revisions used all come from DEPS. Does this need an issue?

We have made a conscious decision not to do this for all builds because we want to make sure everything always builds a head. DEPS is updated when doing a release, and at other adhoc times.

I'd be willing to do all CI with DEPS if we had an autoroller, to essentially always keep DEPS at head. Or we could get 1 build to build with DEPS to make sure it always works. We will consider this. Thanks.