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

[Roland Westrelin]

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.
>> 
>>