This broke 14 GL_NV_shader_atomic_int64 piglit tests (on Navi 14), e.g. tests/spec/nv_shader_atomic_int64/execution/ssbo-atomicAdd-int.shader_test:

In D87674#2290548, @madhur13490 wrote:

The revert also highlights the problem that we don't have representative test in llvm/test :(

This completely broke the Mesa radeonsi driver on Navi 14. Xorg + xterm come up with major corruption & psychedelic colours.

In D82194#2116198, @alex-t wrote:

Could you please advice on how to reproduce the failure and how to collect the failed shaders assembly?
Is MESA_DEBUG set is enough?

This change broke thousands of piglit gpu profile tests with Mesa radeonsi on Navi 14.

This fixes radeonsi on Navi 14, thanks.

This pretty much broke the world with radeonsi on Navi 14:

FWIW, this fixes the regression I reported, without regressing any other tests I run.

This broke glamor with the radeonsi driver, hits unreachable():

I can confirm Mesa now works with this patch, however, it still breaks 9 lit tests for me:

In D49065#1161120, @mareko wrote:

This patch along with the prerequisite patch doesn't break Mesa.

Never mind, I think I confused WQM and WWM.

This isn't necessary. Exports can't enable pixels that weren't enabled in the first place.

No regressions in piglit gpu.py on Kaveri.

In D23131#640613, @calexil wrote:

this commit breaks color rendering for amdgpu/radeon users and causes icons/etc to appear oversaturated red.

https://u.teknik.io/lqpTR.png

please revert or revise this

This breaks test/CodeGen/AMDGPU/llvm.SI.gather4.ll for me:

Thanks Matt, but it occurred to me in the meantime that we could just update Mesa master for the new intrinsic name instead. Any takers?

In D16328#332364, @nhaehnle wrote:

(And as an aside, I feel we should absolutely avoid changes to LLVM that break Mesa silently.

In D16328#331398, @arsenm wrote:

Is it expected that released versions of mesa will work with future llvm releases?

Also, is rematerializing SMRD instructions to save SGPR spills really a win? 64 SGPRs can be spilled to a single VGPR, but the rematerialized SMRD instruction is only cheap if the loaded value is still in cache, right?