Sirraide wrote:
> An effect is more than its flags: its type is an identity, e.g.
> `nonblocking`, `nonallocating` and maybe soon `tcb("name")` (In the Discourse
> thread, there were concerns about overlap with TCB, and this design really
> wants to support an improved TCB that can analyze indirect calls). In the TCB
> case, identity is all that matters, and none of the flags will matter.
> Identity is also the straightforward way to implement the concept of
> `nonblocking` being a superset of `nonallocating` in a number of places that
> check.
I see yeah, that makes sense.
I have some more thoughts on this that I’d like to bring up: if the flags are
really just implied by the identity of each effect, then is there a reason we
can’t ‘just’ use attributes directly and store them as type sugar in the form
of an `AttributedType` rather than in the `FunctionProtoType`? I recall
discussing or seeing a discussion about this at some point, but it’s been a
while and my memory isn’t the best when it comes to thing like these.
Iirc one problem was that the `AttributedType` doesn’t store the actual
attribute at the moment; however, we can look into changing that since this has
caused problems in the past and refactoring it would make sense (I’ve also
talked to Aaron about this before when we noticed problems w/ attributes on
lambdas; a pr that fixes some of those problems is still waiting for a review:
#85325).
At the same time, one possible concern I do have is that while we try to
preserve type sugar if possible, it’s also really easy to ‘accidentally’ drop
it (e.g. `Ty->getAs<FunctionProtoType>()` and then
`getContext()->getFunctionType()` to rebuild the type and all the type sugar is
gone all of a sudden), so we’d have to be very careful about that in places
where it matters at least (because an effect system that sometimes just...
doesn’t work isn’t particularly useful imo).
The reason I’m bringing all of this up is that my main concern is that we may
just end up reinventing attributes, because entities that are named, attached
to types, and add ‘extra’ information while ‘not really’ being part of the type
and which are just ignored by most parts of the compiler—that just sounds a lot
like attributes to me.
So I suppose the situation is this: *ideally*, we’d just be able to use
attributes, but I don’t know off the top of my head how rigorous we are wrt
preserving type sugar; I unfortunately could see ensuring we never drop the
attributes being more work than just making it part of the function type proper
and dealing w/ the consequences... I’m honestly not entirely sure what the best
approach would be. So, I’d say keep the current implementation as is (except
for minor things that like e.g. whether flags should be cached or computed etc.
we can still discuss what to about that; that’s a minor design detail in the
grand scheme of things here imo)—that is, as part of the `FunctionProtoType`.
At this point, I’d really like to know what some of the more experienced
maintainers’ opinions on this are. I’m hoping that @AaronBallman or someone
else might eventually have time to come take a look at this—particularly at the
more fundamental design decisions that we need to make here...
https://github.com/llvm/llvm-project/pull/84983
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
