[PATCH] D32605: Recognize CTLZ builtin

[Evgeny Stupachenko via Phabricator via llvm-commits]

evstupac added a comment.

In https://reviews.llvm.org/D32605#750296, @joerg wrote:

> In https://reviews.llvm.org/D32605#750243, @evstupac wrote:
>
> > In https://reviews.llvm.org/D32605#750202, @joerg wrote:
> >
> > >   if the CPU has no direct lowering for the intrinsic, this transform is beneficial only if the resulting intrinsic can be constant folded
> >
> >
> > Why?
> >  What about converting loop to countable?
> >  What about clear range of CTLZ(X):  0 <= CTLZ(X) <= bitwidth(X)?
>
>
> I don't think this transform changes anything about the countability of the loop, SCEV should certainly be able to do


It changes. SCEV is unable to get BECount for while (n>>=1) loop. Actually BECount should be CTLZ(n) - 1...

>> There should be at least 3 instructions in the loop: add, shift and branch. For 32 bit instruction it will run 16 iterations average, so 16 * 3 > 19.
> 
> You are miscounting. The very example you originally gave trades a shift+count based loop into a clz + increment based loop. Naively speaking without subtleties of the architecture,
>  that saves one instruction in the loop. Any expansion of clz will be worse most of the time.

If we get rid of a loop I'm not miscounting.
If loop is just converted to countable other optimizations are applicable like unroll, LSR, vectorization... with potential great impact.

> The udivmodsi4.S implementation in compiler-rt is a good example -- if clz can be used, it provides a nice optimization. Otherwise the stupid linear checking performs better in the majority of cases. Please keep also in mind that we are talking about potentially executing fewer instructions vs blowing up .text here.

If we apply the optimization only in case whole loop is converted to CTLZ this is ok?
If just convert to countable - then there could be corner cases, which we can guard with TTI for architects that get regressions (if we get).


Repository:
  rL LLVM

https://reviews.llvm.org/D32605