RFR(S): 8149745: C2 should optimize long accumulations in a counted loop

[Vladimir Ivanov]

Roland,

+       Node* ratio_idx = MulINode::make(bt, conv_phi, ratio);

A typo? Shouldn't MulNode::make be used?

Best regards,
Vladimir Ivanov

On 2/15/16 12:09 PM, Roland Westrelin wrote:
> Thanks for looking at this, Vladimir. Here is a new webrev:
>
> http://cr.openjdk.java.net/~roland/8149745/webrev.01/
>
>> incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable?
>
> Done.
>
>> Add assert before next line assert(opc == Op_AddI || opc == Op_AddL
>> +     BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG;
>
> Done.
>
>> May need to add cast (jlong)stride2->get_int() to make all CC happy:
>> jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long();
>
> Done.
>
>> You need to add new ConvI2LNode(init2) in case bt == T_LONG:
>>
>> Node* diff = SubNode::make(bt, init2, ratio_init);
>
> I don’t think it’s required. init2 is an input to the Phi of type long when bt == T_LONG.
>
> Roland.
>
>>
>> Otherwise this looks good.
>>
>> Thanks,
>> Vlaidmir
>>
>> On 2/12/16 7:53 AM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~roland/8149745/webrev.00/
>>>
>>> This extends the code that looks for a parallel induction variable to long accumulations so in the following code:
>>>
>>> public static long testLongAcc() {
>>>     long acc = 0;
>>>
>>>     for (int i = 0; i < 1000; i++) {
>>>         acc += 8;
>>>     }
>>>
>>>     return acc;
>>> }
>>>
>>> the loop is optimized out.
>>>
>>> What I find puzzling is that code for integer accumulations doesn’t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it’s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop?
>>>
>>> Roland.
>>>
>>>
>