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

[Tom Rodriguez]

Andrew Dinn wrote:
> 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.

MembarNodes in graal aren't particularly special as far as memory 
optimization goes.  Any fixed node which is a MemoryCheckpoint can have 
the required graph effects, so a specialized read node should work just 
as well.


> 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.

A NonEmittingMembarNode is just a MembarNode with barriers == 0, so no 
need for a new node I think.

tom

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