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

[Dean Long]

On 9/22/2014 11:42 PM, Lindenmaier, Goetz wrote:
>
> 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.
>
The reason I asked about Encode and not Decode is because my understanding
of 8051805 is that the problem is only for a TEMP RegN.  Unlike RegP, a RegN
is always treated as an oop.

> 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!
>
Any suggested fix is welcome :-)

dl

> 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/62858d88/attachment-0001.html>