libclc: Add Mesa/SPIR-V target

[daniels]

Summary

Add targets to emit SPIR-V targeted to Mesa's OpenCL support, using
SPIR-V 1.1.

Substantially based on Dave Airlie's earlier work.

libclc: spirv: remove step/smoothstep apis not defined for SPIR-V

libclc: disable inlines for SPIR-V builds

[daniels]

Just as an FYI, this is what we are actually using together with a few WIP branches in Mesa. Of note is that we run the LLVM StructurizeCFG pass before generating SPIR-V, else vtn chokes on it, even with the WIP Mesa structuriser.

[daniels]

@jvesely @tstellar I think this should be good for you to both review and land. We've been using this in multiple drivers within Mesa (the OpenCL-on-DirectX backend, software llvmpipe, Nouveau), and it seems to work for us all so far.

[tstellar]

libclc/spirv-mesa3d-dxil/lib/subnormal_config.cl

1 ↗

(On Diff #255494)

What's going on with this file? Is subnormal_config.cl a new file?

[daniels]

libclc/spirv-mesa3d-dxil/lib/subnormal_config.cl

1 ↗

(On Diff #255494)

It was copied and then just had its functionality decimated. I don't know what's going on with the copyright year, though. Should I just resubmit with the header reconciled?

[tstellar]

libclc/spirv-mesa3d-dxil/lib/subnormal_config.cl

1 ↗

(On Diff #255494)

So git tracked the copy? I think it would be less confusing if you updated the patch, so that this is just a new file.

[daniels]

libclc/spirv-mesa3d-dxil/lib/subnormal_config.cl

1 ↗

(On Diff #255494)

Yeah, git just does that under the scenes. It's not an explicit request, but it helpfully finds that for you. Even if you somehow break through that, Phabricator will also automatically reconstruct it for you too. I don't think there's a practical way to subvert this.

[tstellar]

LGTM.

[jenatali]

libclc/spirv-mesa3d-dxil/lib/SOURCES

2 ↗

(On Diff #255494)

We should add ../../generic/lib/async/async_work_group_strided_copy.cl and ../../generic/lib/async/wait_group_events.cl here too.

[jvesely]

libclc/CMakeLists.txt

113

automagic build targets are not nice, because they can fail silently.
I don't mind having dxil in ALL, but an error check if the user selected dxil and llvm-spirv tools were not found would be useful.

269

This path is unnecessarily duplicating a lot of setup form none path.
Moving the spirv special case in a separate condition block below and only setting the extra flags would be a lot cleaner with fewer duplicated lines.

273

"-DCLC_${arch}" can be added globally for all targets.

275

build_flags and opt_flags would be more readable.

306

${dflags} should be in target_compile_definitions rather than target_compile_options

[jenatali]

It looks like we also need to add _CLC_OVERLOAD to the declaration and definitions of the functions declared in workitem as well as barrer(). The LLVM->SPIR-V converter requires these function names to be mangled in order to appropriately translate them to the dedicated SPIR-V built-ins. The names are not mangled for C/CLC unless overloading is requested.

[daniels]

In D77589#2073820, @jenatali wrote:

It looks like we also need to add _CLC_OVERLOAD to the declaration and definitions of the functions declared in workitem as well as barrer(). The LLVM->SPIR-V converter requires these function names to be mangled in order to appropriately translate them to the dedicated SPIR-V built-ins. The names are not mangled for C/CLC unless overloading is requested.

I'll submit that as a separate change. I don't have a good way to test Clover at the moment, so I have to dig out the relevant Clover/llvmpipe branches and get them built.

libclc/CMakeLists.txt

113

We already have the same for amdgcn-mesa-mesa3d, which won't be available unless LLVM >= 3.9 is used. So would you like me to always add the SPIR-V targets to all, then fail the build if the SPIR-V tools are not present but the user has selected (either through all or explicitly) to build the SPIR-V targets?

[daniels]

Updated after review

[jvesely]

thanks!

[daniels]

Rebased on top of master

[daniels]

clang-format changes, seemingly silently generated by arc lint?

[daniels]

Hmm, another new failure, this time because clang-tidy is newly running on the CL source files, and doesn't like them. Should I just blacklist all the libclc source files?

[daniels]

PR to make clang-tidy not try to parse CLC source: https://github.com/google/llvm-premerge-checks/pull/202

[daniels]

That PR was merged to fix the build failure, and now we have a new failure ... https://github.com/google/llvm-premerge-checks/issues/207

[daniels]

Third time's a charm - the CI now passes. Can someone please push this when you're ready?

[bbrezillon]

libclc/CMakeLists.txt

286

Looks like the --spirv-ocl-builtins-version has been renamed to --spirv-target-env (see https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/667bf137eeda7af93b482552c8959376e9565fc1#diff-8b7efcbcbffdd234c43aeda3bb73eaa5), and AFAICT, this should have been --spirv-ocl-builtins-version="CL1.2".
Maybe we can just drop this option since CL1.2 seems to be the default anyway.

[daniels]

Removed builtins version per @bbrezillon, rebase

[daniels]

I've rebased this against current master whilst fixing @bbrezillon's comment.

@tstellar @jvesely Can one of you please land this, D83473: libclc: Fix FP_ILOGBNAN definition, and D82078: libclc: Make all built-ins overloadable? We are ready to merge the SPIR-V libclc support into Mesa for multiple drivers now, but are blocking on this being merged into LLVM trunk.

libclc/CMakeLists.txt

286

Updated, thanks!