RFR: 8216392: Enable cmovP_mem and cmovP_memU instructions

[Roman Kennke]

How should I proceed with this issue? Personally, I don't consider it
important enough to dig deeper into it. Should I close it as wontfix?

Roman

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190218/a64098c4/signature-0001.asc>