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

[silviu.baranga at arm.com]

Hi Sanjoy,

In http://reviews.llvm.org/D10161#192468, @sanjoy wrote:

> I'll make it a point to do a more detailed review this week, but I
>  have a high level question:
>
> Instead of a separate AssumingScalarEvolution, why not have an
>  interface like:
>
>   NoOverflowResult ScalarEvolution::proveNoOverflow(SCEVAddRecExpr
>
> *AddRec, FlagType, bool CanAddAssumptions);


I actually started from something similar, but ended up moving to the current form as it seemed cleaner and the loop vectorizer doesn't need the flexibility (if something doesn't come out as a SCEVAddRecExpr it will fail).

I think the users actually want to get a SCEVAddRecExpr (or a SCEVConstant if possible) form a normal SCEV. It is possible to parse the SCEV and, figure out if there are any assumptions that can be made and add them somewhere.

It would also be incorrect in this case to set the nuw/nsw bits (which didn't seem ideal).

Another problem is that ScalarEvolution's expression cache really gets in the way.

> NoOverflowResult can be Yes, No or (if CanAddAssumptions is true) a

>  predicate that, if satisfied, will guarantee AddRec does not overflow

>  in the FlagType sense.  Then the client can choose if it is profitable

>  to actually emit the predicate if it is cheap enough relative to expected

>  payoff.

> 

> A much more general interface could be

> 

>   Result ScalarEvolution::provePredicate(CmpInst::Pred, SCEV *LHS, SCEV *RHS)

>    

> 

> and have it return one of "Yes | No | Guarded (Predicate)"

> 

> Then not only can you ask the "sext{addrec} == addrec{sext}" question

>  to check for no-wrap, but also push more general logic into

>  ScalarEvolution as needed in the future (i.e. is this add-rec equal to this

>  other add-rec at any iteration? if not, can I make it so by adding runtime

>  checks?).

> 

> - Sanjoy


That would be also one way to do it. We would probably need some utility functions to drive that interface. The initial solution would be at the exact opposite side of the spectrum (easy to use, but not flexible).

Cheers,
Silviu


http://reviews.llvm.org/D10161

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