RFR: 8216392: Enable cmovP_mem and cmovP_memU instructions

[Andrew Dinn]

On 19/01/2019 13:42, B. Blaser wrote:
> I'm definitely not an expert in this area but does ADLC treat this
> really differently from a single LoadP / mov?
> 
> http://hg.openjdk.java.net/jdk/jdk/file/683a112e0e1e/src/hotspot/cpu/x86/x86_64.ad#l5349
You are looking in the wrong place to answer that question. The place
where handling of cases might differ is not in the rule file but in the
implementation of the bottom_type method in the node classes associated
with those rules. That's a tad more difficult to check than meets they
eye at first glance.

The implementation of bottom_type for built-in nodes is in the relevant
classes defined in the opto tree headers. However for machine node
classes it is determined by the code which gets generated when the adlc
preprocessor consumes the rules included in the ad file. So, although
the rules in question here look uniform the derivation of the relevant
bottom types is not guaranteed to be the same. Indeed, that is how it
looks to me. The case handling for rules which match CMove does not
appear (to me) to be able to deal with memory inputs correctly.
Different case handling applies for rules which match LoadP or LoadN and
I very much hope (and expect) it generates code which does compute
bottom types correctly but I have not checked it. I could probably work
out what the differences between the two cases are if I spent the time
studying the code but I'm assuming (hoping :-) someone here knows how it
works and can avoid the need for me to put in that effort.

I would strongly advise against employing these rules without a
guarantee -- from someone who understands the code -- that the comment
about miscomputation of bottom types is not (no longer?) valid. The
rules may have generated valid code in all the cases they have matched
against so far. However, it is the nature of pattern-based programming
models that unexpected matches can turn up at some point and screw the
pooch. Even with existing uses there /might/ be as yet untested compile
contexts where re-ordering of instructions based on miscomputed bottom
types could manifest. It's vital to correctness that the compiler knows
which memory slices instructions are operating on, meaning it's equally
as important that these bottom types are computed correctly.

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