[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