[PATCH] Handle some cases of mismatched types in IRCE

hfinkel at anl.gov hfinkel at anl.gov
Fri Jan 23 18:52:33 PST 2015


In http://reviews.llvm.org/D7082#112917, @sanjoy wrote:

> > Intentional or not, I think this is a bad idea. The results of an analysis should not depend on what transformations were run previously, but only on the current state of the IR. Do you agree?
>
>
> Agreed.  It was mildly confusing when I could not reproduce the issue
>  with an IR dump taken before the pass was run in clang.


Alright, let's fix this then ;)

> 

> 

> > If nothing else, there should at least be a loud warning about it on the interface to getBackedgeTakenCount in ScalarEvolution.h. I'd rather fix this so that we can get the backedge count of the proper size (maybe we need a better updating interface in SE? -- IndVars seems to *have* the correct updated BETC).

> 

> 

> Currently the only precedent for updating cached information in a

>  ScalarEvolution object are the forget.* family of functions.  Will

>  adding anything more fine grained than these

>  ("widenLoopBackedgeTakenCount") be a layering violation?


Why does calling SE->forgetLoop(L) (as is done on line 2024), not clear the cache used to answer the SE->getBackedgeTakenCount(L) query (on line 2025)? Or am I misunderstanding something?

> 

> 

> - Sanjoy

> 

> > REPOSITORY

> 

> > 

> 

> >   rL LLVM

> 

> > 

> 

> > http://reviews.llvm.org/D7082

> 

> > 

> 

> > EMAIL PREFERENCES

> 

> > 

> 

> >   http://reviews.llvm.org/settings/panel/emailpreferences/

> 



REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7082

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






More information about the llvm-commits mailing list