[Verifier] Ban GEP, load, store of addrspace(8) on AMDGPU

[krzysz00]

Summary

AMDGPU buffer resources (address space 8) have a complex
representation (they're 80 bits of metadata followed by 48 bits of
address) and a complex set of addressing modes (such as structured
buffer addressing, which separates out an "index" and "offset" and
allow for things like in-hardware swizzling). While these resources
are represented as pointers to enable alias analysis and other
pointer-based reasoning, they must not be manipulated using standard
LLVM instructions.

This commit adds the cases to the LLVM verifier needed to prohibit
such usage.

Depends on D146761

[foad]

llvm/lib/IR/Verifier.cpp

3875

It feels wrong to me to have target-dependent checks in the IR verifier, but I don't know if it is actually prohibited.

TT crept into the verifier in D65686 as a way to implement object-file-format-dependent checks.

[arsenm]

We don't have any real target specific verifier checks like this now. I do think we need some kind of target IR verifier, but just dropping this in like this is probably not the way to go about it

llvm/lib/IR/Verifier.cpp

3876–3878

Can use GEP.getAddressSpace().

This also will miss constant expressions

[krzysz00]

I wasn't sure if the general IR verifier is the absolute best place, but it already has calling-convention specific checks, which, at least in our case, are target specific.

[arsenm]

In D146762#4236828, @krzysz00 wrote:

I wasn't sure if the general IR verifier is the absolute best place, but it already has calling-convention specific checks, which, at least in our case, are target specific.

Calling conventions aren't quite the same, even if you always only ever use the calling convention on a specific target in the real world. It's not changing the semantics of a core IR construct based on a target check

[krzysz00]

This is my proposed stopgap measure to stop people from tripping over the target -specitic rule we'd need that you can't take offsets of buffer resources except through the arguments to our intrinsics.

Doing this in a less hacky way is probably equivalent to @nhaehnle 's proposal for structured GEP, where we'd gain a data layout flag for "these pointers have inherently complex addressing modes, you can't GEP them correctly".