This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]