Re: Committed: atomic support for CRIS

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: Mike Stump <mikestump@comcast.net>
> CC: "rth@redhat.com" <rth@redhat.com>, "gcc-patches@gcc.gnu.org"
> 	<gcc-patches@gcc.gnu.org>
> Date: Wed, 13 Jun 2012 17:06:39 +0200
> References: <201206122347.q5CNlVKZ030795@ignucius.se.axis.com>
> x-spam-status: No, score=-1.9 required=5 tests=[BAYES_00=-1.9,
> 	FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
> 	autolearn=ham
> x-spam-score: -1.9
> Content-Type: text/plain; charset="us-ascii"
> Old-Content-Transfer-Encoding: quoted-printable
> X-RBL-Checked: 10.0.5.75 10.0.5.78 10.20.1.12 127.0.0.1 76.96.62.19 76.96.62.24
> Content-Transfer-Encoding: 8bit
> MIME-Version: 1.0
> 
> On Jun 12, 2012, at 4:47 PM, Hans-Peter Nilsson wrote:
> >> From: Richard Henderson <rth@redhat.com>
> >> Date: Tue, 12 Jun 2012 23:04:02 +0200
> > Putting a lot of trust onto users and libraries there, to choose
> > the right model...
> 
> My take, very, very few people will actually write code that
> plays with models and barriers...  Just like in the past.
> Instead, people will layer prettier apis on top of it and
> explain the world through that lens and people will use those.
> In the compiler and compiler libraries, we merely provide all
> the primitives necessary for a api implementor to squeeze out
> all the performance they need.  We fail when we leave
> performance on the table in terms of having extra operations
> that aren't necessary, as that limits the utility of the
> library.

Much ado about nothing.  No news. :)

My take is that I won't add useless things to the port that have
no practical value, like another copy-paste instance of
<cpu>_{pre,post}_atomic_barrier (model) (all alike).  But, if
there had been a generic version or helper function, I'd
probably have used it (say, bool generate_barrier_p (enum
memmodel, bool pre)).  A barrier should be created on either but
maybe-not both sides of the atomic operation.  I took the safe
route to do both (when at all), so no memory accesses can sneak
in "behind" the atomic operation.  If this causes an extra
barrier to be added, it will have zero performance effect for
this architecture; there are no scheduling opportunitites
(blessed "sneaking") between the atomic operation and the
barrier anyway.  If one barrier too little is added for one
reason or another: welcome rare bugs.

On the other hand, I should have added a comment with the more
diplomatic version of the above near the code rth quoted. :)

brgds, H-P