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

[Eli Friedman]

On Thu, Oct 28, 2010 at 2:23 PM, Brian West <bnwest at rice.edu> wrote:
> Eli Friedman <eli.friedman <at> gmail.com> writes:
>> > Empirically the OSR optimization is compile-time faster than LSR. I have
>> > also noticed that OSR has more "analysis" requirements: Induction Variable
>> > User, Natural Loop Information, Canonicalize natural loops, and Scalar
>> > Evolution Analysis. Both OSR and LSR require the Dominator Tree Construction
>> > analysis pass.
>>
>> My primary concern here is that if this code gets committed without
>> anyone interested in actually using it, it will just end up orphaned,
>> so there's no point to contributing it.
>
> This work is part of the PACE project (http://pace.rice.edu/).  My team has
> funding for another three years and is committed to maintaining this code.

Okay, good to know.

>> > 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.

-Eli