RFR: 8216392: Enable cmovP_mem and cmovP_memU instructions

[Roman Kennke]

Hi Andrew,

>> While poking around x86_64.ad's cmovP instructions (because I needed it
>> for an experiment in Shenandoah), I noticed that 2 of them are
>> disabled/commented-out:  cmovP_mem and  cmovP_memU. This means that a
>> cmovp with a 2nd argument that is a LoadP will generate two instructions:
>>
>> mov %r1, $mem
>> cmov %r2, %1
>>
>> instead of just one:
>>
>> cmov %r2, $mem
>>
>> The comment there says that adlc doesn't compute the bottom-type
>> correctly, and that implicit null-checking is broken, but I couldn't
>> confirm either of those. I checked hg annotate, but the commented-out
>> block stems from revision #1 and cannot be traced to a bug or so.
> 
> I'm not an expert on aldc but I suspect that the first comment cannot
> simply be ignored -- even if it appears to work in the cases you have tried.
> 
> adlc needs to know bottom types both for memory nodes and for machine
> nodes which coalesce memory ops via rule reductions. This is necessary
> in order to ensure that ops which affect the same memory slices are
> scheduled in the correct order.
> 
> Code in files output_h.cpp ad output_c.cpp generates implementations of
> a virtual method that retrieves the bottom type for such nodes. CMoveP
> instructions are handled as a special case (in output_h.cpp) by
> computing the meet of the bottom types of the first and second ins for
> the associated node.
> 
> That's ok when the ins correspond to standard form inputs. However, I'm
> not sure it will correctly handle a rule containing a rule with a memory
> form input. Memory inputs are a fiction which corresponds to more than
> one in node. I think this may end up computing the bottom type using the
> bottom type of the base address without taking into account any offset.
> That might well cause nasty errors in the computation of some types.
> 
> Perhaps someone from the compiler team can comment on this?

Yeah, I agree, but I couldn't tell or figure out where and how exactly
it's wrong. And since the comment is from changeset #1, and no bug
referenced, etc, it's hard to find out. And it might also be possible
that it was due to the buggy impl that it was (using 32bit reg instead
of 64). Would be good if somebody from compiler team in Oracle could
comment on it.

Roman


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