Re: [RFC] LKMM: Add volatile_if()

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Jun 09, 2021 at 06:13:00PM +0200, Marco Elver wrote:
> 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.

First off, it is not GCC's problem if LLVM decides to use a GCC
extension in some non-compatible way.

It might be possible to extend statement attributes to arbitrary
statement expressions, or some subset of statement expressions, but that
then has to be written down as well; it isn't obvious at all what this
woould do.

> 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

C++ attributes have different syntax *and semantics*.  With GCC
attributes it isn't clear what statement something belongs to (a
statement can contain a statement after all).

C++ requires all unknown attributes to be ignored without error, so can
this be useful at all here?

> > 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.

You would use the builtin to mark exactly where you are making the
control dependency.

(And what is a "conditional control statement"?  Yes of course I can
imagine things, but that is not good enough at all).

> Hence the suggestion for a very simple attribute, which also
> side-steps this problem.

And introduces many more problems :-(


Segher