RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jan 22 08:08:38 PST 2013


On 1/22/13 3:44 AM, Roland Westrelin wrote:
>> All combinations: 1-2,2-3,1-3. Will need additional check in process_expensive_nodes() to do nothing if c1==c2 (got it from processing previous pairs).
>
> I don't understand why it's better than keeping a flat list. The combinations can be easily built from the list once sorted.

Yes, flat list can be used also. If you prefer it, I would not object. 
The only thing I really want is to check if you have similar nodes in 
first stop_early check.

Actually, why you don't do this optimization as normal loop opt after 
splitIf optimization?:

if (!C->major_progress() && process_expensive_nodes()) {
   C->set_major_progress();
}

Current implementation will disturb sequence of loop opts invocations.

>
>>> 1- Move the node up the dominator tree along paths with same frequency
>>
>> In my second mail I suggested to do it in build_loop_early() method where you have early_ctrl for data inputs.
>
> But 2- can bring more opportunities to do 1- again.

Yes, but loop opts executed several times. Why you want to do everything 
during one iteration?

Vladimir

>
>>
>>> 2- Handle If with same computation in both branches
>>> 3- Check for computation that dominates another computation
>>>
>>> 1- and 2- is done in a loop until no more progress.
>>>
>>> You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop?
>>>
>>> I wrote the code in process_expensive_nodes() so that it optimizes this correctly:
>>
>> Which should collapse to calls only before loop. Right?
>
> Yes.
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list