[PATCH] D135202: [IR] Add an opaque type to LLVM.

[Joshua Cranmer via Phabricator via llvm-commits]

jcranmer-intel added a comment.

In D135202#3860361 <https://reviews.llvm.org/D135202#3860361>, @nikic wrote:

> I couldn't find where this has been pointed out, could you please link me to it? I don't really get why it wouldn't be feasible, given that your current proposal effectively already does it, just with a hardcoded `ptr` type.

https://discourse.llvm.org/t/rfc-adding-opaque-types-to-llvm-ir/65326/10 was what I was thinking of, but looking back, it's not as thorough as I thought it was.

The broad issue with opaque types in general is that there's not necessarily an underlying type. For SPIR-V, it's the case that these types almost always [1] ultimately lower into a `ptr` (of some address space) or a `i32` type (or `i32`-stored-as-a-`ptr`), so pretending that these types are `ptr` is a viable strategy--indeed, this is what the current SPIR-V target lowering does. I don't know @asb's WASM use case very well, but I imagine treating opaque types as a `ptr` in a trenchcoat would similarly ultimately work correctly.

Look past these use cases, however, and underlying types get murkier. It's true that I didn't account for these yet, but that was more a matter of punting on design decisions that didn't need addressing for this specific use case. If `x86_mmx` and `x86_amx` were implemented as opaque types [2], their underlying type is murkier--perhaps vectors of 64 bit and 8,192 bit respectively, but what vector element type would you pick for them? Some of the exotic hardware I've worked on (whose details are unfortunately not public) could find an opaque type useful, but those types can't find any underlying type that would be useful--something like `opaque("hw", float)` would mean "you can get a `float` from me", but treating it as a `float` in a trenchcoat would be absolutely catastrophic.

My biggest worry with trying to use underlying types is that it would encourage people to think of opaque types as "it's really just a T" when the entire point of opaque types is that it has to be treated **differently** from a T.

[1] Read as "this is the case in every backend I checked", which is admittedly a very far cry from "all of them". Although the chosen address space does vary between different targets, `ptr addrspace(0)` is sufficiently pessimistic for size/alignment information.
[2] I'm not proposing doing this, but they do provide some useful checks for what might be relevant.

>> But I could add optional type properties that would include size and alignment to start with (and have those default to `sizeof(ptr)` and size, respectively)--how does that sound?
>
> That would be fine as well, though probably harder to implement.

Type properties are already something I've considered necessary anyways, and size/alignment is a very natural place to start; I didn't include them in this patch principally because the code I had didn't need them yet (as relying on the default being `ptr` was sufficient for my needs, although I now see that it caused more reviewer confusion than I anticipated).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135202/new/

https://reviews.llvm.org/D135202