Messages in this thread | | | From | Marco Elver <> | Date | Wed, 9 Jun 2021 18:13:00 +0200 | Subject | Re: [RFC] LKMM: Add volatile_if() |
| |
On Wed, 9 Jun 2021 at 17:33, Segher Boessenkool <segher@kernel.crashing.org> wrote: [...] > > An alternative design would be to use a statement attribute to only > > enforce (C) ("__attribute__((mustcontrol))" ?). > > Statement attributes only exist for empty statements. It is unclear how > (and if!) we could support it for general statements.
Statement attributes can apply to anything -- Clang has had them apply to non-empty statements for a while. I have [[clang::mustcontrol]]/__attribute__((mustcontrol)) working, but of course it's not final but helped me figure out how feasible it is without running in circles here -- proof here: https://reviews.llvm.org/D103958
If [1] is up-to-date, then yes, I can see that GCC currently only supports empty statement attributes, but Clang isn't limited to empty [2]. [1] https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html [2] https://clang.llvm.org/docs/AttributeReference.html#statement-attributes
In fact, since C++20 [3], GCC will have to support statement attributes on non-empty statements, so presumably the parsing logic should already be there. [3] https://en.cppreference.com/w/cpp/language/attributes/likely
> Some new builtin seems to fit the requirements better? I haven't looked > too closely though.
I had a longer discussion with someone offline about it, and the problem with a builtin is similar to the "memory_order_consume implementation problem" -- you might have an expression that uses the builtin in some function without any control, and merely returns the result of the expression as a result. If that function is in another compilation unit, it then becomes difficult to propagate this information without somehow making it part of the type system. Therefore, by using a statement attribute on conditional control statements, we do not even have this problem. It seems cleaner syntactically than having a __builtin_() that is either approximate, or gives an error if used in the wrong context.
Hence the suggestion for a very simple attribute, which also side-steps this problem.
Thanks, -- Marco
| |