[LLVMdev] Landing my new development on the trunk ...

Brian West bnwest at rice.edu
Fri Oct 29 11:18:48 PDT 2010


Eli Friedman <eli.friedman <at> gmail.com> writes:
 > >> > I did not mention in the original email (and should have) that 
OSR needs
 > >> > -instcombine to be run after it for cleanup. Also -licm, 
-reassociate, -gvn
 > >> > and -sccp can be enabling optimizations for OSR.
 > >>
 > >> Hmm... perhaps that could be partially fixed using the InstSimplify
 > >> infrastructure.
 > >
 > > OSR can produce induction variables that are not used.  
-instcombine finds the
 > > unused induction variables and deletes them (which is super cool 
btw :)).  I am
 > > unsure if InstructionSimplify can fix that.
 >
 > Oh... no, you would need instcombine for that.  However, how hard
 > would it be to just avoid creating unused induction variables?
 > instcombine doesn't normally run after LSR.


Short answer is no.

The OSR adds new induction variables based on existing variables.  That 
way, we
can go from induction variable i to induction variable &a[long(i)] (aka, a +
long(i)).   There may be some intermediate induction variables that 
assist in i
reaching (a + long(i)), like long(i), e.g.

i -> long(i) -> (a + long(i))

after creating (a + long(i)), induction variable long(i) may be unused,
depending on whether long(i) can participate in creating an another 
induction
variable. Thus, it is not known until the algorithm is done, which of the
created induction variables are unused.

FWIW I noticed that other optimizations (as seen in StandardPasses.h) are
followed by -instcombine for cleanup. I thought requiring or suggesting 
running
-instcombine after -osr would be SOP.

FWIW2 our intent in creating OSR was not to replace LSR, just provide an
alternative strength reduction optimization.


 > -Eli


Brian




More information about the llvm-dev mailing list