RFR (S): 8058880: Introduce identifier TEMP_DEF for effects in adl.

[Lindenmaier, Goetz]

Hi Dean,

thanks for the tip.  I would assume the same holds for Decode, as the TEMP RegP
could be GC'ed, too.
But we use postalloc_expand to replace the node two nodes.  First, we can use
RegL for the problematic edge avoiding it's handled by build_oop_map, and second
this allows to schedule the mov earlier.  Because of the problem you mention we
can not use the normal expand.  USE_DEF where the use is RegL and the def RegP
is not supported by the register allocation.

For 8051805, I think placing the TEMPS before their uses is an essential property
of the IR.  Maybe build_oop_map should check that it's valid!

Best regards,
  Goetz

From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
Sent: Dienstag, 23. September 2014 03:49
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (S): 8058880: Introduce identifier TEMP_DEF for effects in adl.

Hi Goetz.  Do you anticipate using TEMP_DEF for EncodeP as well?  If so,  be aware that you may
run into problems because of 8051805.

dl
On 9/22/2014 6:17 AM, Lindenmaier, Goetz wrote:
Hi,

this change introduces a new identifier in adl:
http://cr.openjdk.java.net/~goetz/webrevs/8058880-tempDef/webrev.00/<http://cr.openjdk.java.net/%7Egoetz/webrevs/8058880-tempDef/webrev.00/>
https://bugs.openjdk.java.net/browse/JDK-8058880

Please review this change.  I please need a sponsor.

This effect is similar to USE_DEF, except that a TEMP node will be generated
that represents the USE.

With this effect one can express that the def'ed register must be
different from the used ones corresponding to ins. Currently this is
already possible by specifying effect TEMP for the operand with effect
DEF from the match rule.

Introducing this new identifier makes the code more readable and
allows to specify the effect for nodes without match rules.

An example is an optimized encode node, if the base of the compressed heap
is 35G aligned, i.e., the shifted narrow oop can be merged with the base by
an or instruction.
On PPC we can shift and or with a single instruction:

decodeN(dst, src):

mov    Rdst = Rbase
rldimi Rdst = Rdst || (Rsrc << 3)

As the move is off the critical path, this is superior to do a shift and an add.
Unfortunately we must guarantee that Rdst != Rsrc. which we do with a TEMP_DEF effect:

instruct decodeN(iRegPdst dst, iRegNsrc src) %{
  match(Set dst (DecodeN src));
  effect(TEMP_DEF dst);

As requested before, I fixed the syntax in the code around my change.

Thanks and best regards,
  Goetz.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140923/dd3eb323/attachment.html>