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 cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits