[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

Duncan P. N. Exon Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 25 16:17:40 PDT 2022


dexonsmith added a comment.

I think dropping struct names from intrinsic return types is a bit unfortunate. I wonder if there's a way to keep them?

For context, I've been imagining the following transition for named structs:

1. Opaque pointers. (This removes all cycles in the Type graph.)
2. Refactor named structs into a pointer to "unnamed struct" (immutable) + "a name".
3. "Remove" named structs, moving the name field to a map in Module (and, maybe, a map per-Function to override).
  - `getType()` always refers to an "unnamed struct".
  - Textual IR would print the name assigned by the owner (instruction checks map in Function (if we have that), then Module). `Instruction::print()` can do the same.
  - (Requires (1), which removes all cycles in the Type graph.)
4. (All `Type`s are now immutable. Refactor accordingly.)
5. (Make `get()` and `create()` thread-safe for types by using a thread-safe insert-only data structure.)
6. (various other things...)

(More context than needed/useful, probably; also, I'm aware that (3) has caveats / hasn't been proposed / etc.)

My point: once (2) is done, it would be trivial to check for two different named types whether they were structurally equivalent. At point, you could have module-specific names on structs returned from intrinsics.

I wonder if doing (2) now (before opaque pointers is done) would be possible/useful, and if it'd help keeping names here?

Or, maybe, names on struct types returned by intrinsics just aren't very valuable? (since they're rare / small / easy enough to reason about?)


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

https://reviews.llvm.org/D122471



More information about the llvm-commits mailing list