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