Mangling intrinsics with opaque pointer arguments using "op"+{address space}.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
maybe we should make a quick post on llvm-dev about this to see what other people think, since this will be very user-visible
llvm/lib/IR/Verifier.cpp | ||
---|---|---|
1843 ↗ | (On Diff #352012) | we still want some of the checks below, for example, we want to check !Attrs.getByValType()->isSized() |
(generally looks like the right direction to me - sounds like @aeubanks has some good feedback/issues to address)
The patch looks mostly good, but I'm not sold on "op". Can we just use "p"?
llvm/test/Verifier/opaque-ptr.ll | ||
---|---|---|
34 | This is actually not the correct name, it should end with op0. We should add a CHECK line for the actual name. |
The patch looks mostly good, but I'm not sold on "op". Can we just use "p"?
Presumably then we wouldn't know whether to parse a type after the address space or not? Unless we only support this when everything is opaque pointers? (so there can be no confusion between opaque pointers or not)
IIUC, we don't really care about the exact name, just that it doesn't conflict with another declaration of the same intrinsic but with different parameter types. This is unambiguous even when non-opaque pointers are in the picture, since non-opaque pointers will always have something after the p0.
It seems what's after "{intrinsic}." is not important for IR parsing: https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/IntrinsicInst.cpp#L127.
lgtm, now that I understand intrinsics a bit more, this seems trivial enough to not need input from llvm-dev
Though currently the mangling scheme does allow arbitrary overloading, I think, yeah? If we don't allow arbitrary overloading of intrinsics with the same name, but only use the mangling to fix different parameter types while always having the same number of parameters, then it's probably fine. (then we'd only hit ambiguities in really niche cases maybe?)
But with this change we couldn't overload some intrinsic with "(ptr, int)" and "(ptr)" because they'd produce the same mangling in the case where the former was an opaque pointer and the latter was a typed int pointer?
But we probably don't actually do that?
Oh, I just went and looked more - and now I see that the mangled parameter types are . separated, so the ambiguities I thought could occur (is p0i8 an opaque pointer followed by an i8 or a typed pointer-to-i8? Not actually ambiguous, because opaque pointer followed by i8 would be p0.i8 instead).
Carry on!
This is actually not the correct name, it should end with op0. We should add a CHECK line for the actual name.