[PATCH] [SCEV][LoopVectorize] Allow ScalarEvolution to make assumptions about overflows

silviu.baranga at arm.com silviu.baranga at arm.com
Tue Jun 23 09:37:55 PDT 2015


Hi Andy,

Thanks for looking at this!

In http://reviews.llvm.org/D10161#192391, @atrick wrote:

> Overall, it's great to see something like this working in practice. In the past, several alternatives have been discussed. IIRC the main objection to this approach is that SCEV could make assumptions that are not necessary for the optimization leading to overhead for unnecessary checks.


Would that be on the list? If so, it would be an interesting read.
Yes, in theory this can produce unnecessary checks. I think it works ok for the vectorizer (since any case where we wouldn't make this assumption would result in not vectorizing). It looks like a trade-off between not having all the users deal explicitly with this against the number of memchecks.

> On most targets, I think it's more efficient to check the high bits for overflow. e.g.

> 

>   if ((a + 0x800000) & 0xffffff000000) overflow

>    

> 

> Instead of:

> 

> +    if (Signed) {

>  +      APInt CmpMinValue = APInt::getSignedMinValue(DstBits).sext(SrcBits);

>  +      ConstantInt *CTMin = ConstantInt::get(M->getContext(), CmpMinValue);

>  +      Value *MinCheck = OFBuilder.CreateICmp(ICmpInst::ICMP_SLT,

>  +                                             TripCount,

>  +                                             CTMin);

>  +      TripCountCheck = OFBuilder.CreateOr(TripCountCheck, MinCheck);

>  +    }


Nice. I wonder if the optimizers handle well the cases where we would test some consecutive values with this method, or if we don't end up generating something similar anyway.

Thanks,
Silviu


http://reviews.llvm.org/D10161

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list