[llvm-dev] visitShiftByConstant of DAGCombiner

[Jojo Ma via llvm-dev]

Hi,

I recently worked on doing constant canonicalisation in DAGCombine level to
make as more folding as possible.
And I found the behavior of "visitShiftByConstant" is same with what I have
done, just only it only be enabled under
 a shift context. But I think maybe we could expand it to as more case as
possible.

 The original issuse of it:

For code as below:

unsigned array[4];
unsigned foo(unsigned long x) {
          return array[(x>>2)&3ul];

sequence before this canonicalisation (ARM):

foo:
.fnstart
@ BB#0:                                 @ %entry
lsrs r0, r0, #2
movs r1, #3
ands r1, r0
lsls r0, r1, #2
ldr r1, .LCPI0_0
ldr r0, [r1, r0]
bx lr
.p2align 2

sequence after this canonicalisation:
foo:
.fnstart
@ BB#0:                                 @ %entry
movs r1, #12
ands r1, r0
ldr r0, .LCPI0_0
ldr r0, [r0, r1]
bx lr
.p2align 2


This canonicalisation makes shift folding possible. But I wonder if only
shift context could benifit from this.When I worked on
CoreMark optimization recently, I found a case similar to below:

define i32 @test(i32 %v) {
entry:
  %a = and i32 %v, 65534
  %b = lshr i32 %a, 1
  %c = and i32 %v, 65535
  %d = lshr i32 %c, 1
  %e = add i32 %b, %d
  ret i32 %e
}

It would be profitable as well if we could enable the canonicalisation on
it.
sequence before this canonicalisation (ARM):
test:
.fnstart
@ BB#0:                                 @ %entry
movw r1, #65534
and r1, r0, r1
ubfx r0, r0, #1, #15
add r0, r0, r1, lsr #1
bx lr

sequence after this canonicalisation:
test:
.fnstart
@ BB#0:                                 @ %entry
ubfx r0, r0, #1, #15
add r0, r0, r0
bx lr

But when I tried to expand the condition to this case, there are lots of
various regression fails.
The expanding may prevent some other possible folding or something. Maybe I
missed something or
the expanding is not reasonable at all.but I didn't figure out yet.
Any suggestions? Any inspiration is highly appreciated.

And there maybe some other cases could be included also. If you have any
findings, please let
me know as well.

Thank you very much! :)

Best Regards,
Jojo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161208/7f4701ae/attachment.html>