[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