dougsonos wrote:
> I understand that you’d want to avoid allocating memory for effects over and
> over again, but at the same time—I think it’s fine to just don’t cache effect
> sets at all.
I agree that this would be simpler and fine.
> Each effect has a set of properties, which are represented as flags.
...
> As I see it, either all of an effect’s properties should be modelled as
> flags, or none should be (mixing the two sounds like the most complicated
> approach), and if we’re doing the former, then I don’t think there is a point
> in storing anything other than just the flags.
An effect is more than its flags: an identity, which can be `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.
So that rules out the idea of reducing an effect to those flags.
But yes, an effect need not hold anything more than its type/identity (and for
TCB, a "subtype" that mapped to its name/identity). The flags are commented as
being cached in the `FunctionEffect` as a convenience/optimization since there
is space. But they definitely don't **have** to be there and could be simply
returned as constants, mapped from the type. I would agree that that would make
things clearer.
https://github.com/llvm/llvm-project/pull/84983
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
