[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)

Doug Wyatt via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 10 11:07:25 PDT 2024


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


More information about the cfe-commits mailing list