[llvm-commits] Teach SCEV about {X,*,Y} recursions

[Török Edwin]

Chris Lattner wrote:
>
> On Apr 23, 2008, at 1:58 PM, Török Edwin wrote:
>
>> Hi,
>>
>> I have a patch that adds support for exponential recursions in loops.
>> This is useful in static analysis tools, and also for code optimization.
>
> This is interesting, but a couple questions:
>
> 1) What sort of code does this really help with in practice?  I'm a
> bit afraid of adding a bunch of complexity to SCEV analysis if it is
> unlikely to be useful for broad code.  Do you see power sequences
> indexing arrays for example?

It is useful if we can compute the loop exit value of a variable without
actually executing the loop (e.g. compute a^1980 w/o looping 1980
times), and thus the variable can
be moved out of the loop, and we can possibly delete the loop entirely.

If that variable is used for something else inside the loop (indexing an
array), then we get no advantage, we still need to loop N times, and
actually it is better to keep the original mul in this case.

I see that powexpr got generated for at least these:
pifft, consumer-lame, telecomm-fft, voronoi, np, scimark2.

I'll try to see if performance is actually improved in a real situation.

On the (stupid) testcase I wrote in
test/Analysis/ScalarEvolution/mulrec.ll the difference is 0.4 seconds
vs. 0.002 seconds (even if I move the test() func in a different file to
prevent computing the result at compile-time).

>
> 2) instead of having SCEVExpander::visitPowExpr emit multiplies, it
> should emit a call to llvm.powi.

I would need a powi that takes an integer argument as a base.
I don't want to introduce FP code where there wasn't any before. Also it
would currently force us to link the resulting code with -lm, right?
Should I add a powi that takes an integer base?

>
> 3) It would be really nice to teach the code generator to lower
> llvm.powi nicer, particularly before something like this patch goes
> in.  Our current lowering of powi is pretty naive.

AFAICT it is just transformed into a libcall. Would you like me to move
the constant-power codegen code there?

Best regards,
--Edwin