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: 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.
>
> 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, determined by
> the type. I would agree that that would make things clearer.
https://github.com/llvm/llvm-project/pull/84983
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
