What does this actually fix?
This is likely to pessimize codegen for graphics quite badly. Graphics APIs make fairly strong aliasing guarantees which we don't properly express in LLVM at the moment, and we kind of get by without it by having s.buffer.load be readnone.
When trying to do some global isel work, I ran into inconsistencies in the attributes (e.g. D63422), and I don't want to spread awareness of this hack to more places. We can't really fix this until we have fat pointers. I would rather have the declaration be accurate. If graphics users want to assume readnone as a performance hack until that is fixed, they can annotate every call site with readnone.
Okay, I think changing the intrinsic to readonly is fine. Mesa sets readnone on the callsite.
That said, I do see lit test failures which should be the same as the Mesa problems. Could you please also add a test (or modify a test) in llvm.amdgcn.s.buffer.load.ll which sets readnone on the callsite?
This has a possibly negative impact on Mesa. Both SGPR usage and SGPR spilling increased. I don't see anything suspicious in the generated assembly other than instructions being reordered. I'd like to better understand the side effects of this patch.
Note that Mesa does set readnone on call sites.