On Fri, Jun 04, 2021 at 06:10:55PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 04, 2021 at 10:35:18AM -0500, Segher Boessenkool wrote:
> > On Fri, Jun 04, 2021 at 01:44:37PM +0200, Peter Zijlstra wrote:
> > > On naming (sorry Paul for forgetting that in the initial mail); while I
> > > think using the volatile qualifier for the language feature (can we haz
> > > plz, kthxbai) makes perfect sense, Paul felt that we might use a
> > > 'better' name for the kernel use, ctrl_dep_if() was proposed.
> >
> > In standard C statements do not have qualifiers. Unless you can
> > convince the ISO C committee to have them on "if", you will have a very
> > hard time convincing any serious compiler to do this.
>
> While some people like talking to the Committee, I would much rather
> explore language extensions with the compiler communities. Such
> extensions can then make their way into the Committee once they show
> their usefulness.
My point is that you ask compiler developers to paint themselves into a
corner if you ask them to change such fundamental C syntax.
> If you have another proposal on how to express this; one you'd rather
> see implemented, I'm all ears.
I would love to see something that meshes well with the rest of C. But
there is no 1-1 translation from C code to machine code (not in either
direction), so anything that more or less depends on that will always
be awkward. If you can actually express the dependency in your source
code that will get us 95% to where we want to be.
> Data dependencies, control dependencies and address dependencies, C
> doesn't really like them, we rely on them. It would be awesome if we can
> fix this.
Yes. The problem is that C is a high-level language. All C semantics
are expressed on a an "as-if" level, never as "do this, then that" --
well, of course that *is* what it says, it's an imperative language just
like most, but that is just how you *think* about things on a conceptual
level, there is nothing that says the machine code has to do the same
thing in the same order as you wrote!
Segher
On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> On Fri, Jun 04, 2021 at 06:10:55PM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 04, 2021 at 10:35:18AM -0500, Segher Boessenkool wrote:
> > > On Fri, Jun 04, 2021 at 01:44:37PM +0200, Peter Zijlstra wrote:
> > > > On naming (sorry Paul for forgetting that in the initial mail); while I
> > > > think using the volatile qualifier for the language feature (can we haz
> > > > plz, kthxbai) makes perfect sense, Paul felt that we might use a
> > > > 'better' name for the kernel use, ctrl_dep_if() was proposed.
> > >
> > > In standard C statements do not have qualifiers. Unless you can
> > > convince the ISO C committee to have them on "if", you will have a very
> > > hard time convincing any serious compiler to do this.
> >
> > While some people like talking to the Committee, I would much rather
> > explore language extensions with the compiler communities. Such
> > extensions can then make their way into the Committee once they show
> > their usefulness.
>
> My point is that you ask compiler developers to paint themselves into a
> corner if you ask them to change such fundamental C syntax.
Once we have some experience with a language extension, the official
syntax for a standardized version of that extension can be bikeshedded.
Committees being what they are, what we use in the meantime will
definitely not be what is chosen, so there is not a whole lot of point
in worrying about the exact syntax in the meantime. ;-)
> > If you have another proposal on how to express this; one you'd rather
> > see implemented, I'm all ears.
>
> I would love to see something that meshes well with the rest of C. But
> there is no 1-1 translation from C code to machine code (not in either
> direction), so anything that more or less depends on that will always
> be awkward. If you can actually express the dependency in your source
> code that will get us 95% to where we want to be.
>
> > Data dependencies, control dependencies and address dependencies, C
> > doesn't really like them, we rely on them. It would be awesome if we can
> > fix this.
>
> Yes. The problem is that C is a high-level language. All C semantics
> are expressed on a an "as-if" level, never as "do this, then that" --
> well, of course that *is* what it says, it's an imperative language just
> like most, but that is just how you *think* about things on a conceptual
> level, there is nothing that says the machine code has to do the same
> thing in the same order as you wrote!
Which is exactly why these conversations are often difficult. There is
a tension between pushing the as-if rule as far as possible within the
compiler on the one hand and allowing developers to write code that does
what is needed on the other. ;-)
Thanx, Paul
On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> > My point is that you ask compiler developers to paint themselves into a
> > corner if you ask them to change such fundamental C syntax.
>
> Once we have some experience with a language extension, the official
> syntax for a standardized version of that extension can be bikeshedded.
> Committees being what they are, what we use in the meantime will
> definitely not be what is chosen, so there is not a whole lot of point
> in worrying about the exact syntax in the meantime. ;-)
I am only saying that it is unlikely any compiler that is used in
production will want to experiment with "volatile if".
> > I would love to see something that meshes well with the rest of C. But
> > there is no 1-1 translation from C code to machine code (not in either
> > direction), so anything that more or less depends on that will always
> > be awkward. If you can actually express the dependency in your source
> > code that will get us 95% to where we want to be.
^^^
> > > Data dependencies, control dependencies and address dependencies, C
> > > doesn't really like them, we rely on them. It would be awesome if we can
> > > fix this.
> >
> > Yes. The problem is that C is a high-level language. All C semantics
> > are expressed on a an "as-if" level, never as "do this, then that" --
> > well, of course that *is* what it says, it's an imperative language just
> > like most, but that is just how you *think* about things on a conceptual
> > level, there is nothing that says the machine code has to do the same
> > thing in the same order as you wrote!
>
> Which is exactly why these conversations are often difficult. There is
> a tension between pushing the as-if rule as far as possible within the
> compiler on the one hand and allowing developers to write code that does
> what is needed on the other. ;-)
There is a tension between what users expect from the compiler and what
actually is promised. The compiler is not pushing the as-if rule any
further than it always has: it just becomes better at optimising over
time. The as-if rule is and always has been absolute.
What is needed to get any progress is for user expectations to be
feasible and not contradict existing requirements. See "^^^" above.
Segher
On Fri, Jun 04, 2021 at 02:53:01PM -0500, Segher Boessenkool wrote:
> On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> > > My point is that you ask compiler developers to paint themselves into a
> > > corner if you ask them to change such fundamental C syntax.
> >
> > Once we have some experience with a language extension, the official
> > syntax for a standardized version of that extension can be bikeshedded.
> > Committees being what they are, what we use in the meantime will
> > definitely not be what is chosen, so there is not a whole lot of point
> > in worrying about the exact syntax in the meantime. ;-)
>
> I am only saying that it is unlikely any compiler that is used in
> production will want to experiment with "volatile if".
That unfortunately matches my experience over quite a few years. But if
something can be implemented using existing extensions, the conversations
often get easier. Especially given many more people are now familiar
with concurrency.
> > > I would love to see something that meshes well with the rest of C. But
> > > there is no 1-1 translation from C code to machine code (not in either
> > > direction), so anything that more or less depends on that will always
> > > be awkward. If you can actually express the dependency in your source
> > > code that will get us 95% to where we want to be.
>
> ^^^
>
> > > > Data dependencies, control dependencies and address dependencies, C
> > > > doesn't really like them, we rely on them. It would be awesome if we can
> > > > fix this.
> > >
> > > Yes. The problem is that C is a high-level language. All C semantics
> > > are expressed on a an "as-if" level, never as "do this, then that" --
> > > well, of course that *is* what it says, it's an imperative language just
> > > like most, but that is just how you *think* about things on a conceptual
> > > level, there is nothing that says the machine code has to do the same
> > > thing in the same order as you wrote!
> >
> > Which is exactly why these conversations are often difficult. There is
> > a tension between pushing the as-if rule as far as possible within the
> > compiler on the one hand and allowing developers to write code that does
> > what is needed on the other. ;-)
>
> There is a tension between what users expect from the compiler and what
> actually is promised. The compiler is not pushing the as-if rule any
> further than it always has: it just becomes better at optimising over
> time. The as-if rule is and always has been absolute.
Heh! The fact that the compiler has become better at optimizing
over time is exactly what has been pushing the as-if rule further.
The underlying problem is that it is often impossible to write large
applications (such as the Linux kernel) completely within the confines of
the standard. Thus, most large applications, and especially concurrent
applications, are vulnerable to either the compiler becoming better
at optimizing or compilers pushing the as-if rule, however you want to
say it.
> What is needed to get any progress is for user expectations to be
> feasible and not contradict existing requirements. See "^^^" above.
Or additional requirements need to be accepted by the various compilation
powers that be. Failing to acknowledge valid new user expectations is
after all an excellent path to obsolescence.
Thanx, Paul
On Fri, Jun 04, 2021 at 01:40:42PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 04, 2021 at 02:53:01PM -0500, Segher Boessenkool wrote:
> > On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> > > > My point is that you ask compiler developers to paint themselves into a
> > > > corner if you ask them to change such fundamental C syntax.
> > >
> > > Once we have some experience with a language extension, the official
> > > syntax for a standardized version of that extension can be bikeshedded.
> > > Committees being what they are, what we use in the meantime will
> > > definitely not be what is chosen, so there is not a whole lot of point
> > > in worrying about the exact syntax in the meantime. ;-)
> >
> > I am only saying that it is unlikely any compiler that is used in
> > production will want to experiment with "volatile if".
>
> That unfortunately matches my experience over quite a few years. But if
> something can be implemented using existing extensions, the conversations
> often get easier. Especially given many more people are now familiar
> with concurrency.
This was about the syntax "volatile if", not about the concept, let's
call that "volatile_if". And no, it was not me who brought this up :-)
> > > Which is exactly why these conversations are often difficult. There is
> > > a tension between pushing the as-if rule as far as possible within the
> > > compiler on the one hand and allowing developers to write code that does
> > > what is needed on the other. ;-)
> >
> > There is a tension between what users expect from the compiler and what
> > actually is promised. The compiler is not pushing the as-if rule any
> > further than it always has: it just becomes better at optimising over
> > time. The as-if rule is and always has been absolute.
>
> Heh! The fact that the compiler has become better at optimizing
> over time is exactly what has been pushing the as-if rule further.
>
> The underlying problem is that it is often impossible to write large
> applications (such as the Linux kernel) completely within the confines of
> the standard. Thus, most large applications, and especially concurrent
> applications, are vulnerable to either the compiler becoming better
> at optimizing or compilers pushing the as-if rule, however you want to
> say it.
Oh definitely. But there is nothing the compiler can do about most
cases of undefined behaviour: it cannot detect it, and there is no way
it *can* be handled sanely. Take for example dereferencing a pointer
that does not point to an object.
Segher
On Sun, Jun 06, 2021 at 06:36:51AM -0500, Segher Boessenkool wrote:
> On Fri, Jun 04, 2021 at 01:40:42PM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 04, 2021 at 02:53:01PM -0500, Segher Boessenkool wrote:
> > > On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:
> > > > > My point is that you ask compiler developers to paint themselves into a
> > > > > corner if you ask them to change such fundamental C syntax.
> > > >
> > > > Once we have some experience with a language extension, the official
> > > > syntax for a standardized version of that extension can be bikeshedded.
> > > > Committees being what they are, what we use in the meantime will
> > > > definitely not be what is chosen, so there is not a whole lot of point
> > > > in worrying about the exact syntax in the meantime. ;-)
> > >
> > > I am only saying that it is unlikely any compiler that is used in
> > > production will want to experiment with "volatile if".
> >
> > That unfortunately matches my experience over quite a few years. But if
> > something can be implemented using existing extensions, the conversations
> > often get easier. Especially given many more people are now familiar
> > with concurrency.
>
> This was about the syntax "volatile if", not about the concept, let's
> call that "volatile_if". And no, it was not me who brought this up :-)
I agree that it is likely that the syntax "volatile if" would be at best
a very reluctantly acquired taste among most of the committee. But some
might point to the evolving semantics of "auto" as a counter-example,
to say nothing of the celebrated spaceship operator. Me, I am not
all that worried about the exact syntax.
> > > > Which is exactly why these conversations are often difficult. There is
> > > > a tension between pushing the as-if rule as far as possible within the
> > > > compiler on the one hand and allowing developers to write code that does
> > > > what is needed on the other. ;-)
> > >
> > > There is a tension between what users expect from the compiler and what
> > > actually is promised. The compiler is not pushing the as-if rule any
> > > further than it always has: it just becomes better at optimising over
> > > time. The as-if rule is and always has been absolute.
> >
> > Heh! The fact that the compiler has become better at optimizing
> > over time is exactly what has been pushing the as-if rule further.
> >
> > The underlying problem is that it is often impossible to write large
> > applications (such as the Linux kernel) completely within the confines of
> > the standard. Thus, most large applications, and especially concurrent
> > applications, are vulnerable to either the compiler becoming better
> > at optimizing or compilers pushing the as-if rule, however you want to
> > say it.
>
> Oh definitely. But there is nothing the compiler can do about most
> cases of undefined behaviour: it cannot detect it, and there is no way
> it *can* be handled sanely. Take for example dereferencing a pointer
> that does not point to an object.
Almost.
The compiler's use of provenance allows detection in some cases.
For a stupid example, please see https://godbolt.org/z/z9cWvqdhE.
Less stupidly, this sort of thing can be quite annoying to people trying
to use ABA-tolerant concurrent algorithms. See for example P1726R4
[1] (update in progress) and for an even more controversial proposal,
P2188R1 [2]. The Lifo Singly Linked Push algorithm described beginning
on page 14 of [1] is a simple example of an ABA-tolerant algorithm that
was already in use when I first programmed a computer. ;-)
Thanx, Paul
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1726r4.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2188r1.html