[LLVMdev] Missing InstCombine optimization.

Bader, Aleksey A aleksey.a.bader at intel.com
Tue Jun 4 06:27:42 PDT 2013


Hi Jakob,

I've a problem related to the commit #155362.

Consider the following snippet:
void bar(float* f) {
...
}
void foo(float* f, int idx) {
int hi = idx>>3;
int lo = idx&7;
bar(&f[hi*8+lo]); // hi*8 + lo == idx
bar(&f[hi*10+lo]);
}

Before 155362 revision InstCombine was able to optimize hi*8+lo to idx by applying following patterns:

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.

Thanks,
Aleksey

--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/e9b8f677/attachment.html>


More information about the llvm-dev mailing list