[aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far

[Roland Westrelin]

Hi Andrew,

> I'll take your word for it that the matcher problem Stuart ran into can
> be fixed by the tweak you applied to Matcher::clone_address_expressions.
> I don't know what ZBarrierSetC2::matcher_find_shared_visit is meant to
> do, never mind how it interacts with clone_address_expressions. However,
> I don't see any problem having clone_address_expressions return false on
> AArch64 when the address is being consumed by a LoadStore.

A field load is:

(LoadI (AddP base field_offset))

and we want a single instruction that embeds the address calculation.

2 field load of the same field would be:

(LoadI (AddP base field_offset))
(LoadI (AddP base field_offset))

with a shared AddP. When c2 performs matching, if it sees a node that is
shared such as this one, it matches it as a standalone mach node. So we
would have an instruction to compute the field address and 2 loads that
use the result of that instructions. Given how cheap it is to let the
memory access instruction do the address calculation, that's not what we
want. Instead we want the matcher to operate as if there are 2 different
AddP nodes. That's what cloning in the matcher is about. It doesn't
really clone anything but it makes sure the AddP above is not seen as
shared and matched once for every memory access instructions.

Now with ZGC, I think we can have some field access at some (AddP ...)
address followed by a slow path call to the runtime in the barrier code
that passes that address. So the (AddP ...) is shared between a memory
access node and a call node. That causes it to be matched
separately. Given the call is in the slow path, that's not what we
want. So the ZGC specific code "clones" the AddP in that scenario.

On aarch64, in the case of a cas, the AddP address input is "cloned" but
it's not matched as part of the cas mach node which confuses the matcher
logic. 

Roland.