not sure what I misread here.

fixed issues with check-clang, might need some follow up changes.

missed a couple of hunks.

found a few more places to replace these and fix them up. there might still be some strays in there.

Add @azabaznov

Added a comment on the subgroups difference.

@azabaznov no bad effects here in my initial basic testing with CL 3.0, I'll land this tomorrow or next day when I get a chance.

@azabaznov is this what you meant? I haven't tested this yet as my clang dev box died, but I'll get to it as soon as I can.

added comments.

In D106778#2904509, @Anastasia wrote:

Generally LGTM, but I think we should guard the else blocks with CL_VERSION_2_0 or higher to avoid exposing the functions in earlier standards because the spec says:

The C11 style atomic functions in this sub-section require support for OpenCL 2.0 or newer. However, this statement does not apply to the "OpenCL C 1.x Legacy Atomics" descriptions at the end of this sub-section.

Adding @azabaznov to check if he can suggest anything for testing. Although it seems like this is only related to the new functionality of OpenCL3.0.

In D106778#2904509, @Anastasia wrote:

Generally LGTM, but I think we should guard the else blocks with CL_VERSION_2_0 or higher to avoid exposing the functions in earlier standards because the spec says:

The C11 style atomic functions in this sub-section require support for OpenCL 2.0 or newer. However, this statement does not apply to the "OpenCL C 1.x Legacy Atomics" descriptions at the end of this sub-section.

Adding @azabaznov to check if he can suggest anything for testing. Although it seems like this is only related to the new functionality of OpenCL3.0.

add conditional around memory_order_seq_cst

yeah I agree I'll drop those two changes.

leave version checks alone since they are inside the outer extension check.

fixed up missing cl_khr_subgroups checks.

fixed alternate way.

full diff.

I've dropped the SPIR change in the base header until things are resolved for library SPIR users to disable extension defines.

updated to full diff.

I'll have to rebase/rebuild my build env, I'll try and have something rebasing this cleaner soon.

I've moved a bunch of longer checks into just feature checks and defined the features at the top of the file.

In D92004#2413560, @Anastasia wrote:

Btw how about making some checks simpler. We could always define feature macros __opencl_c_atomic_scope_device, __opencl_c_generic_address_space for OpenCL 2.0 or C++ for OpenCL . Then everywhere we would only need to check feature macros instead of language versions and feature macros together.

#if !(defined()) && (defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0))
#define __opencl_c_atomic_scope_device      1
#define __opencl_c_generic_address_space   1
...
#endif

this file has never been clang-format clean, happy to make changes if reviewer decides they are needed.

I don't have commit access, can someone please push this.

Rebased onto latest master. I require someone else to push this as I don't have commit rights.

Thanks for the review, Chandler,

At the moment this is more than an assert fix, we have broken VI in favour of GFX9 which nobody has. Please get a workaround, revert or fix into llvm master asap.

Looks good to me, I regression tested a few things with it in geom/tess shader land and they seemed fine.

Consider this a bug report for Sam, I'm not even sure where to start writing a test.

radv regression looks related do ds_bpermute interactions if I had to guess.

This adds support for the x2/x4 paths. Probably could be done better, and I've tested this with a few vulkan games.

fixed a regression in the when to emit spill setup path, should have just added isMesaGfx option not removed the other one.

fix pedantry
fix two bugs found in testing.

updates after taking to Tom on irc, still might cause a flag day.

This rewrites the patch, using a new triple OsType (needs renaming to something better), and adds an intrinsic to get access to the private buffer.

Updated diff to spill to a 64-bit buffer, pointed to by 64-bits in the buffer pointed to by SGPR0/1.

In D25428#565912, @arsenm wrote:

I think ABI changes should be encoded as part of the triple (a radv environment type?) rather than a subtarget feature. This is supposed to be just the pointer and not the full scratch resource descriptor?

FYI: The current mesa side of this is here:
https://github.com/airlied/mesa/tree/radv-wip-spilling