RFR(M): 8080289: Intermediate writes in a loop not eliminated by optimizer
Vitaly Davidovich
vitalyd at gmail.com
Tue Jun 23 16:48:13 UTC 2015
Hmm, so no barriers *at all* if IRIW is true, as-if these are plain stores?
That does seem wrong.
On Tue, Jun 23, 2015 at 12:29 PM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:
> > So what does the graph look like for this example?
>
> I haven’t checked but I would expect:
>
> ...->MB->->ST(y=2)->MB->ST(x=1)->MB->ST(y=1)->...
>
> if support_IRIW_for_not_multiple_copy_atomic_cpu is false
>
> ...->ST(y=2)->ST(y=1)->...
> ...->ST(x=1)->...
>
> otherwise
>
> Roland.
>
> >
> > sent from my phone
> >
> > On Jun 23, 2015 6:50 AM, "Roland Westrelin" <roland.westrelin at oracle.com>
> wrote:
> >
> > >> What about
> > >>
> > >> volatile int y;
> > >> volatile int x;
> > >>
> > >> y=1
> > >> x=1
> > >> y=2
> > >>
> > >> transformed to:
> > >>
> > >> x=1
> > >> y=2
> > >>
> > >> ?
> > >
> > > I think this is not allowed, since operations over "x" get tied up in
> > > the synchronization order.
> >
> > Thanks. Then for support_IRIW_for_not_multiple_copy_atomic_cpu true, I
> don’t see how incorrect reordering is prevented.
> >
> > Roland.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150623/cee57e3f/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list