Travis hosed yet again, still waiting for pull of PRs #227 and #239, looking to implement weak memory-aware read/writes

[Andrew Dinn]

Hi Tom,

On 20/07/17 18:47, Tom Rodriguez wrote:
> Sorry I didn't push 239 last week but we had a little release emergency.
>  Both 239 and 227 are now in our internal gate and should push today.
> Sorry for the delay.

Thanks very much!

> Would we in general be better off having a VolatileReadNode and a
> VolatileWriteNode that includes the required barriers instead of
> prebarrier/read|write/postbarrier?  That would make this kind of thing
> more of a backend decision. Or do you need to look at nearby barriers
> anyway to produce the best code?

This would probably be a better solution. However, I don't (yet) know
enough about the rest of the compiler phases to be sure what else might
need changing if the Membar nodes are dropped. I was assuming that the
Membar nodes would need to be present in order to ensure that later
graph rewritings don't invalidly re-order other, non-volatile reads and
writes (in particular I was concerned about movement of writes inserted
by GC barriers).

So, that's why I planned to replace the Membar nodes with a non-emitting
variant, leaving the current rewriting logic untouched. If you think the
mere presence of the VolatileRead/WriteNode can be used to ensure that
later phases (and the back end) are able to identify and avoid invalid
re-orderings then I'll happily go that route and work in any required
changes in downstream phases.

I still plan to go ahead and implement the proposed AArch64 patch anyway
as a prototype -- I'll use VolatileRead/WriteNode as the names for the
node classes and introduce a - hopefully temporary NonEmittingMembarNode
class. Once I get that patch ready I will post it for review and you can
see whether it looks like a good candidate for a generic model. If the
NonEmittingMembarNode class can be omitted by making whatever
accompanying changes -- if any -- are needed in later phases then I will
do my best to generalise the code I introduce to work for all architectures.

n.b. I'll happily take whatever advice you have to offer on what to look
out for in the rest of the code base or how else to proceed.

regards,


Andrew Dinn
-----------
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