[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