GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

[Martin Jambor]

Hi,

I have received the following idea for a Google Summer of Code project,
see the quotation from Paul McKenney below (I do not know myself where
exactly it is from).  I consider memory consistency models a very tough
topic and so am doubly reluctant to just post it to wiki without having
a mentor for it.  On the other hand, with the right mentors it
definitely can be quite a remarkable project with a big potential.

Paul, this may come as a surprise for you, but would you be willing to
(co-)mentor such a project if there is a student brave enough to
undertake it?

C++ front-end guys, would you please consider co-mentoring this project
if Paul was willing to do so?

Anybody else interested in getting involved?

Any other suggestions/comments?

Thank you very much in advance,

Martin


-------------------- Start of forwarded message --------------------

Hi Martin,

I don't think I have a mentor for this yet though I wonder if Paul McKenney
could be persuaded for this from the memory model side and someone familiar
with the C++ frontend on the GCC side ?

<quote Paul>
--

One could argue that compilers in fact implement the C and C++
memory_order_consume facility.  However, all known compilers do so by
promoting it to memory_order_acquire, which on weakly ordered systems
can result in unnecessary memory-barrier instructions on your fastpaths,
which might not be what you want.  The reason for the promotion to
memory_order_acquire is the difficutlies faced by compiler writers when
attempting to trace dependencies at the C/C++ source-code level.  In fact,
there is a proposal to temporarily deprecate memory_order_consume [1].

So what is to be done?  One proposal [2] restricts dependency chains
to cases where it is difficult for the compiler to break them, and
further requires that pointer variables carrying dependencies be marked.
(This proposal also includes prototype wording for the C++ standard,
a number of litmus tests, and some discussion.)  Such marking might not
go down well with the Linux kernel community, which has been carrying
dependencies in unmarked variables for more than 15 years, so there is
further informal proposal asking C and C++ implementations to provide a
command-line option forcing the compiler to treat any pointer variable
as if it had been marked.  (Why informal?  Because command-line options
are outside of the scope of the standard.)

There is a prototype implementation that obtains the functionality of
memory_order_consume without actually using memory_order_consume, which
is briefly described in a recent C++ working paper [3].  However, the
committee was not all that happy with this approach, preferring marking
of a single pointer variable to maintaining a separate variable to carry
the dependency.

It would therefore be quite desirable to have an implementation that
allowed pointers to be marked as carrying dependencies, that avoided
the specified dependency-breaking optimizations on such pointers, and
that provided a command-line switch that caused the compiler to treat
all pointers as if they were to marked [2].


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html

---

Ramana
-------------------- End of forwarded message --------------------

Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

[Jason Merrill]

On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor <mjambor@suse.cz> wrote:
>
> I have received the following idea for a Google Summer of Code project,
> see the quotation from Paul McKenney below (I do not know myself where
> exactly it is from).  I consider memory consistency models a very tough
> topic and so am doubly reluctant to just post it to wiki without having
> a mentor for it.  On the other hand, with the right mentors it
> definitely can be quite a remarkable project with a big potential.
>
> Paul, this may come as a surprise for you, but would you be willing to
> (co-)mentor such a project if there is a student brave enough to
> undertake it?
>
> C++ front-end guys, would you please consider co-mentoring this project
> if Paul was willing to do so?

I wouldn't expect this project to touch the C++ front-end at all; any
compiler work would all be in the middle/back-end.  There's some
previous discussion of these issues at

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

So I'd suggest pinging Andrew Macleod.

Jason

> Anybody else interested in getting involved?
>
> Any other suggestions/comments?
>
> Thank you very much in advance,
>
> Martin
>
>
> -------------------- Start of forwarded message --------------------
>
> Hi Martin,
>
> I don't think I have a mentor for this yet though I wonder if Paul McKenney
> could be persuaded for this from the memory model side and someone familiar
> with the C++ frontend on the GCC side ?
>
> <quote Paul>
> --
>
> One could argue that compilers in fact implement the C and C++
> memory_order_consume facility.  However, all known compilers do so by
> promoting it to memory_order_acquire, which on weakly ordered systems
> can result in unnecessary memory-barrier instructions on your fastpaths,
> which might not be what you want.  The reason for the promotion to
> memory_order_acquire is the difficutlies faced by compiler writers when
> attempting to trace dependencies at the C/C++ source-code level.  In fact,
> there is a proposal to temporarily deprecate memory_order_consume [1].
>
> So what is to be done?  One proposal [2] restricts dependency chains
> to cases where it is difficult for the compiler to break them, and
> further requires that pointer variables carrying dependencies be marked.
> (This proposal also includes prototype wording for the C++ standard,
> a number of litmus tests, and some discussion.)  Such marking might not
> go down well with the Linux kernel community, which has been carrying
> dependencies in unmarked variables for more than 15 years, so there is
> further informal proposal asking C and C++ implementations to provide a
> command-line option forcing the compiler to treat any pointer variable
> as if it had been marked.  (Why informal?  Because command-line options
> are outside of the scope of the standard.)
>
> There is a prototype implementation that obtains the functionality of
> memory_order_consume without actually using memory_order_consume, which
> is briefly described in a recent C++ working paper [3].  However, the
> committee was not all that happy with this approach, preferring marking
> of a single pointer variable to maintaining a separate variable to carry
> the dependency.
>
> It would therefore be quite desirable to have an implementation that
> allowed pointers to be marked as carrying dependencies, that avoided
> the specified dependency-breaking optimizations on such pointers, and
> that provided a command-line switch that caused the compiler to treat
> all pointers as if they were to marked [2].
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
>
> ---
>
> Ramana
> -------------------- End of forwarded message --------------------

Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

[Martin Jambor]

Hi Jason and Andrew,

On Mon, Feb 04 2019, Jason Merrill wrote:
> On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor <mjambor@suse.cz> wrote:
>>
>> I have received the following idea for a Google Summer of Code project,
>> see the quotation from Paul McKenney below (I do not know myself where
>> exactly it is from).  I consider memory consistency models a very tough
>> topic and so am doubly reluctant to just post it to wiki without having
>> a mentor for it.  On the other hand, with the right mentors it
>> definitely can be quite a remarkable project with a big potential.
>>
>> Paul, this may come as a surprise for you, but would you be willing to
>> (co-)mentor such a project if there is a student brave enough to
>> undertake it?
>>
>> C++ front-end guys, would you please consider co-mentoring this project
>> if Paul was willing to do so?
>
> I wouldn't expect this project to touch the C++ front-end at all; any
> compiler work would all be in the middle/back-end.  There's some
> previous discussion of these issues at
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
>
> So I'd suggest pinging Andrew Macleod.

All right then, I was wondering what the FE specific parts would be too
but did not have a reason to doubt it.

Andrew, the word has it that Paul McKenney has expressed interest to
co-mentor this Google Summer of Code project, would you be willing to
join him?  The proposal is still copied below for your convenience.

Thanks,

Martin


>
> Jason
>
>> Anybody else interested in getting involved?
>>
>> Any other suggestions/comments?
>>
>> Thank you very much in advance,
>>
>> Martin
>>
>>
>> -------------------- Start of forwarded message --------------------
>>
>> Hi Martin,
>>
>> I don't think I have a mentor for this yet though I wonder if Paul McKenney
>> could be persuaded for this from the memory model side and someone familiar
>> with the C++ frontend on the GCC side ?
>>
>> <quote Paul>
>> --
>>
>> One could argue that compilers in fact implement the C and C++
>> memory_order_consume facility.  However, all known compilers do so by
>> promoting it to memory_order_acquire, which on weakly ordered systems
>> can result in unnecessary memory-barrier instructions on your fastpaths,
>> which might not be what you want.  The reason for the promotion to
>> memory_order_acquire is the difficutlies faced by compiler writers when
>> attempting to trace dependencies at the C/C++ source-code level.  In fact,
>> there is a proposal to temporarily deprecate memory_order_consume [1].
>>
>> So what is to be done?  One proposal [2] restricts dependency chains
>> to cases where it is difficult for the compiler to break them, and
>> further requires that pointer variables carrying dependencies be marked.
>> (This proposal also includes prototype wording for the C++ standard,
>> a number of litmus tests, and some discussion.)  Such marking might not
>> go down well with the Linux kernel community, which has been carrying
>> dependencies in unmarked variables for more than 15 years, so there is
>> further informal proposal asking C and C++ implementations to provide a
>> command-line option forcing the compiler to treat any pointer variable
>> as if it had been marked.  (Why informal?  Because command-line options
>> are outside of the scope of the standard.)
>>
>> There is a prototype implementation that obtains the functionality of
>> memory_order_consume without actually using memory_order_consume, which
>> is briefly described in a recent C++ working paper [3].  However, the
>> committee was not all that happy with this approach, preferring marking
>> of a single pointer variable to maintaining a separate variable to carry
>> the dependency.
>>
>> It would therefore be quite desirable to have an implementation that
>> allowed pointers to be marked as carrying dependencies, that avoided
>> the specified dependency-breaking optimizations on such pointers, and
>> that provided a command-line switch that caused the compiler to treat
>> all pointers as if they were to marked [2].
>>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
>> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
>> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
>>
>> ---
>>
>> Ramana
>> -------------------- End of forwarded message --------------------