[aarch64-port-dev ] RFR: 8204331: AArch64: fix CAS not embedded in normal graph error
adinn at redhat.com
Fri Jun 22 08:30:16 UTC 2018
On 21/06/18 18:49, Roman Kennke wrote:
> thanks so much for fixing this!
> Also, very nice ASCII drawings and explanations! :-)
> As far as I can tell, the patch is good.
Ok, thanks for the review.
> I'm wondering why it's worth to go through that effort to verify the
> correct shape of CAS and similar nodes, and keep maintaining this code
> in light of changes (Shenandoah will be the next headache to fix this).
> Do the instruction only match those particular shapes, and if it
> changes, it'd throw off the matcher badly?
I would very much like to find a better, less fragile solution. The
problem is finding another way to identify whether or not a
Store/Load/CAS needs to translate to acquiring/releasing instructions
and (at the same time) whether memory barrier operations in the graph
need, respectively, to be elided or generated. The specific, complex
graph shapes the predicates test for are indeed unique to volatile
operations and so the presence of these shapes enables the former
strategy to be adopted. If nodes are found not to be embedded in such a
subgraph then they need to be translated via the latter strategy.
Perhaps the relevant nodes could be clearly labelled at create time as
belonging to a volatile load/store/CAS operation. At present there is no
such info in a MemBar node and the memory order property on a load/store
node can indicate that it is an ordered operation even when it has not
been planted because of a volatile load/store/CAS. The danger here would
be losing this info if any nodes were merged or elided by compiler
phases although I am not sure that would ever happen.
For Graal, I managed to finesse this problem by adding extra graph links
from leading membar to Load/Store/CAS to trailing membar. That was
easier to do than it is for C2 because in Graal you can annotate links
with type tags, indicating that they have a specific semantic. Choosing
a special link type makes it possible to avoid breaking the many
algorithms which analyze the graph linkage. I don't really know how to
achieve that in C2.
Roland or Vladimir (take your pick of them ;-) should be in a much
better position to address the merits of these two alternatives than I am.
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the hotspot-dev