[LLVMdev] Missing InstCombine optimization.

Rafael Espíndola rafael.espindola at gmail.com
Tue Jun 4 12:57:33 PDT 2013


> 1.       hi*8 -> hi << 3
>
> 2.       ((idx >> 3) << 3) -> idx & -8
>
> 3.       hi*8+lo -> hi*8 | lo
>
> 4.       (idx & -8) | (idx & 7) -> idx & (-8 | 7) -> idx
>
>
>
> After 155362 pattern #2 is deferred to DAGCombine stage, so InstCombine is
> unable to apply pattern #4:
>
>         4*. ((idx >> 3) << 3) | (idx & 7) -> idx // SimplifyOr can’t handle
> it.
>
>
>
> So now LLVM IR contains a couple of redundant operations:
>
>   %mul312 = shl nsw i32 %shr, 3 ; hi*8
>
>   %add313 = or i32 %mul312, %and ; hi*8 + lo == idx
>
>
>
> These few additional operations over index prevent our analysis pass from
> recognizing memory access patterns and I believe could harm not only us.
>
> I think 4* optimization can be safely done at LLVM IR level.
>
> Can you suggest the best way to fix this issue? I suppose adding new pattern
> just for particular 4* case is not the best way.


We used handle arbitrary  ((idx >> A) << B), right? Maybe it is enough
to handle   ((idx >> A) << A) in instcombine?

Cheers,
Rafael




More information about the llvm-dev mailing list