RFR 8134802 - LCM register pressure scheduling

[Vladimir Kozlov]

We only have 3 bits left since total is 16:

jushort _flags;

You have Flag_is_reduction which is used only in loop opts/superword. So 
you can overlap these flags.

We need to clean up this (no you, Michael). We have flags which are used 
only by Ideal node (Flag_is_macro, Flag_is_expensive). And flags used by 
Mach nodes (5 flags). We may try to overlap them.

Vladimir

On 9/9/15 7:34 PM, Berg, Michael C wrote:
> All, please see the link: https://bugs.openjdk.java.net/browse/JDK-8134802
>
> As I have uploaded a performance report for data collected with/wo register pressure scheduling. I would like to keep the node flag in place, we have room for 15 more flags after this one is added, and this is a formal phase of C2 and so a good use of one the flags.  The addition of VectorSet would incrementally raise the overhead of the algorithm. Please have a look and comment as needed.
>
> Thanks,
> Michael
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, September 04, 2015 6:42 PM
> To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR 8134802 - LCM register pressure scheduling
>
> Impressive work. Thank you for reusing current RA functionality.
>
> "is very minimal" - how minimal? 2% or 10%?
>
> Did it gave any performance improvement? Changes are significant and should be justified.
>
> Changes look reasonable. I only notice one thing:
> Flag bits in Node is very precious to use for node's state tracking. Why not use VectorSet?
>
> Thanks,
> Vladimir
>
> On 9/4/15 1:33 PM, Berg, Michael C wrote:
>> Hi Folks,
>>
>> I would like to contribute LCM register pressure scheduling. I need
>> two reviewers to examine this patch and comment as needed:
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8134802
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~mcberg/8134802/webrev.01/
>>
>> These changes calculate register pressure at the entry of a basic
>> block, at the end and incrementally while we are scheduling. It uses
>> an efficient algorithm for recalculating register pressure on a as
>> needed basis. The algorithm uses heuristics to switch to a pressure
>> based algorithm to reduce spills for int and float registers using
>> thresholds for each. It also uses weights which count on a per
>> register class basis to dope ready list candidate choice while
>> scheduling so that we reduce register pressure when possible. Once we
>> fall over either threshold, we start trying mitigate pressure upon the
>> affected class of registers which are over the limit. This happens on
>> both register classes and/or separately for each. We switch back to
>> latency scheduling when pressure is alleviated. As before we obey hard
>> artifacts such as barriers, fences and such. Overhead for constructing
>> and providing liveness information and the additional algorithmic
>> usage is very minimal, so as affect compile time minimally.
>>
>> Thanks,
>>
>> Michael
>>