RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation.

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 15 12:28:21 PDT 2013


Goetz,

Sorry but currently we don't have time to review this and part 113 
changes. They affect shared code and are relatively big so we need to 
review them carefully. And now we are very very busy with 
fixing/cleaning bugs for jkd8 release. Please, wait 2 more weeks.

Regards,
Vladimir

On 10/15/13 12:15 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> could I please get a review on this change?  I would appreciate any comments.
>
> Thanks and best regards,
>    Goetz.
>
> From: goetz.lindenmaier at sap.com
> Sent: Mittwoch, 2. Oktober 2013 15:49
> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov'
> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation.
>
> Hi,
>
> we extended C2 by what we call lateExpand. LateExpand expands nodes
> after register allocation.
> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/
>
> Some nodes can not be expanded during matching. E.g., register
> allocation might not be able to deal with the resulting pattern. To
> allow better scheduling in such cases, we introduce lateExpand which
> runs after register allocation. Whether and how nodes are expanded is
> specified in the ad-file. See block.cpp for a detailed
> documentation. We use this for some nodes on ppc, and extensively on
> ia64.
> For an example, see the webrev.
>
> We added some utility functions in node.hpp and block.hpp used by
> PhaseCFG::LateExpand() or the Node::lateExpand functions.  Also,
> MachConstantBaseNode gets the two new functions, as we need to
> late expand it.
>
> To skip the walk over the IR if no lateExpand is needed, we use
> Matcher::require_late_expand set in the ad file. This ends up in
> ad_<cpu>.cpp, thus can not be evaluated by the C++ compiler.  If you
> agree, I would use a "const bool EnableLateExpand" in
> globalDefinitions_<cpu>.hpp.  (There is no suitable c2_<xxx>_<cpu>.hpp
> file).
>
> We allready mailed a webrev with this change after last year's
> JavaOne, but there was no discussion on it.
> Again, this change is 'L', but the code is not used on other
> platforms than PPC64 (so far).  So the impact on those platforms
> should be minimal.
>
> Please review and test this change.
>
> Thanks and best regards,
>    Goetz.
>


More information about the hotspot-dev mailing list