Hi Jason and Andrew, On Mon, Feb 04 2019, Jason Merrill wrote: > On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor <mjam...@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 --------------------
