This is the mail archive of the
mailing list for the GCC project.
GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
- From: Martin Jambor <mjambor at suse dot cz>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>, Paul E. McKenney <paulmck at linux dot ibm dot com>
- Cc: Ramana Radhakrishnan <ramana dot r at gmail dot com>, Jason Merrill <jason at redhat dot com>, Nathan Sidwell <nathan at acm dot org>
- Date: Mon, 04 Feb 2019 12:06:23 +0100
- Subject: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
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
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,
-------------------- Start of forwarded message --------------------
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 ?
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 .
So what is to be done? One proposal  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 . 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
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 .
-------------------- End of forwarded message --------------------