This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by krzysz00 on Mar 23 2023, 2:40 PM.

Details

Reviewers
arsenm
nhaehnle
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

Diff Detail

Event Timeline

krzysz00 created this revision.Mar 23 2023, 2:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 23 2023, 2:40 PM
krzysz00 requested review of this revision.Mar 23 2023, 2:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 23 2023, 2:40 PM
foad added a subscriber: foad.Mar 24 2023, 1:06 AM
foad added inline comments.Mar 31 2023, 4:17 AM
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.

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

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.

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

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".