Suboptimal instruction sequence when operands are reordered

[hiraditya]

int foo(int t) {
    return t - (1 - 5 * t);
}

int bar(int t) {
    return t - 1 + 5 * t;
}

int baz(int t) {
    return t + 5 * t - 1;
}

$ riscv64-clang -O3

        .text
        .attribute      4, 16
        .attribute      5, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
        .file   "example.c"
        .globl  foo                             # -- Begin function foo
        .p2align        1
        .type   foo,@function
foo:                                    # @foo
# %bb.0:
        slliw   a1, a0, 2
        addw    a1, a1, a0
        addw    a0, a0, a1
        addiw   a0, a0, -1
        ret
.Lfunc_end0:
        .size   foo, .Lfunc_end0-foo
                                        # -- End function
        .globl  bar                             # -- Begin function bar
        .p2align        1
        .type   bar,@function
bar:                                    # @bar
# %bb.0:
        slliw   a1, a0, 2
        addw    a1, a1, a0
        addw    a0, a0, a1
        addiw   a0, a0, -1
        ret
.Lfunc_end1:
        .size   bar, .Lfunc_end1-bar
                                        # -- End function
        .globl  baz                             # -- Begin function baz
        .p2align        1
        .type   baz,@function
baz:                                    # @baz
# %bb.0:
        li      a1, 6
        mulw    a0, a0, a1
        addiw   a0, a0, -1
        ret
.Lfunc_end2:
        .size   baz, .Lfunc_end2-baz
                                        # -- End function
        .ident  "clang version 16.0.0 (https://github.com/llvm/llvm-project.git 06c02d5dbb13f6d2a10eaa75c236f3c61cdf5b91)"
        .section        ".note.GNU-stack","",@progbits
        .addrsig

In the last case mulw is generated.

Aarch64 also has this issue

$ arm64-clang -O3

        .text
        .file   "example.c"
        .globl  foo                             // -- Begin function foo
        .p2align        2
        .type   foo,@function
foo:                                    // @foo
        .cfi_startproc
// %bb.0:
        add     w8, w0, w0, lsl #2
        add     w8, w8, w0
        sub     w0, w8, #1
        ret
.Lfunc_end0:
        .size   foo, .Lfunc_end0-foo
        .cfi_endproc
                                        // -- End function
        .globl  bar                             // -- Begin function bar
        .p2align        2
        .type   bar,@function
bar:                                    // @bar
        .cfi_startproc
// %bb.0:
        add     w8, w0, w0, lsl #2
        add     w8, w0, w8
        sub     w0, w8, #1
        ret
.Lfunc_end1:
        .size   bar, .Lfunc_end1-bar
        .cfi_endproc
                                        // -- End function
        .globl  baz                             // -- Begin function baz
        .p2align        2
        .type   baz,@function
baz:                                    // @baz
        .cfi_startproc
// %bb.0:
        mov     w8, #6
        mul     w8, w0, w8
        sub     w0, w8, #1
        ret
.Lfunc_end2:
        .size   baz, .Lfunc_end2-baz
        .cfi_endproc
                                        // -- End function
        .ident  "clang version 16.0.0 (https://github.com/llvm/llvm-project.git 06c02d5dbb13f6d2a10eaa75c236f3c61cdf5b91)"
        .section        ".note.GNU-stack","",@progbits
        .addrsig

In the last case mul is generated.

However, X86 generates the same instruction sequence for all three

        .text
        .intel_syntax noprefix
        .file   "example.c"
        .globl  foo                             # -- Begin function foo
        .p2align        4, 0x90
        .type   foo,@function
foo:                                    # @foo
        .cfi_startproc
# %bb.0:
                                        # kill: def $edi killed $edi def $rdi
        lea     eax, [rdi + 4*rdi]
        add     eax, edi
        dec     eax
        ret
.Lfunc_end0:
        .size   foo, .Lfunc_end0-foo
        .cfi_endproc
                                        # -- End function
        .globl  bar                             # -- Begin function bar
        .p2align        4, 0x90
        .type   bar,@function
bar:                                    # @bar
        .cfi_startproc
# %bb.0:
                                        # kill: def $edi killed $edi def $rdi
        lea     eax, [rdi + 4*rdi]
        add     eax, edi
        dec     eax
        ret
.Lfunc_end1:
        .size   bar, .Lfunc_end1-bar
        .cfi_endproc
                                        # -- End function
        .globl  baz                             # -- Begin function baz
        .p2align        4, 0x90
        .type   baz,@function
baz:                                    # @baz
        .cfi_startproc
# %bb.0:
                                        # kill: def $edi killed $edi def $rdi
        lea     eax, [rdi + 2*rdi]
        add     eax, eax
        dec     eax
        ret
.Lfunc_end2:
        .size   baz, .Lfunc_end2-baz
        .cfi_endproc
                                        # -- End function
        .ident  "clang version 16.0.0 (https://github.com/llvm/llvm-project.git 06c02d5dbb13f6d2a10eaa75c236f3c61cdf5b91)"
        .section        ".note.GNU-stack","",@progbits
        .addrsig

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[llvmbot]

@llvm/issue-subscribers-backend-arm

[topperc]

The IR for @foo looks silly @rotateright

define dso_local i32 @foo(i32 noundef %0) local_unnamed_addr #0 {
  %2 = mul i32 %0, -5
  %3 = xor i32 %2, -1
  %4 = add i32 %3, %0
  ret i32 %4
}

[topperc]

The instructions are the same for X86 but the operands are not. The lea for baz uses 2*. The others use 4*

[topperc]

We do better with Zba. We manage a 2 instruction serial dependency for @baz

foo:                                    # @foo
        sh2add  a1, a0, a0
        add     a0, a0, a1
        addi    a0, a0, -1
        ret
bar:                                    # @bar
        sh2add  a1, a0, a0
        add     a0, a0, a1
        addi    a0, a0, -1
        ret
baz:                                    # @baz
        sh1add  a0, a0, a0
        li      a1, -1
        sh1add  a0, a0, a1
        ret

[rotateright]

The IR for @foo looks silly @rotateright

define dso_local i32 @foo(i32 noundef %0) local_unnamed_addr #0 {
  %2 = mul i32 %0, -5
  %3 = xor i32 %2, -1
  %4 = add i32 %3, %0
  ret i32 %4
}

Yeah, I didn't step through the transforms, but I think we want to reduce all of these to baz() form in IR since that's shortest:
https://alive2.llvm.org/ce/z/oZqFop

That means the backend needs more mul expansion smarts if we are trying to avoid the mul in asm.

[rotateright]

However, X86 generates the same instruction sequence for all three

This comment is not correct:

    lea     eax, [rdi + 4*rdi]
    add     eax, edi

...

    lea     eax, [rdi + 4*rdi]
    add     eax, edi

...

    lea     eax, [rdi + 2*rdi]
    add     eax, eax

In the baz() case, it decomposed as (3x) + (3x), but the others were 5*x + x. I don't think that makes a perf difference on any recent CPU, but it does show that we could do better at canonicalizing in codegen too?

[hiraditya]

This comment is not correct:

Yeah, missed it. But w.r.t. performance all three will be similar while for Arm and Riscv there is difference.

I don't think that makes a perf difference on any recent CPU, but it does show that we could do better at canonicalizing in codegen too?

agreed!

[vfdff]

Fixes AArch64 part with https://reviews.llvm.org/D132322

[rotateright]

On the IR side, we could generalize the factoring to patterns with no constants:
https://alive2.llvm.org/ce/z/mbsDdE
That's likely better in IR since it eliminates a use of 'x', but it's probably worse in codegen for most targets (especially if they have a 'madd' instruction).

[rotateright]

On the IR side, we could generalize the factoring to patterns with no constants: https://alive2.llvm.org/ce/z/mbsDdE That's likely better in IR since it eliminates a use of 'x', but it's probably worse in codegen for most targets (especially if they have a 'madd' instruction).

On 2nd thought, madd codegen looks fine either way (at least for aarch64):

src:
	add	w8, w0, w2
	madd	w0, w0, w1, w8
tgt:
	madd	w8, w0, w1, w0
	add	w0, w8, w2

The 'tgt' form with dependent ops might have a longer critical path without madd, but that should be invertible in codegen.

[rotateright]

Proposal to improve canonicalization in IR:
https://reviews.llvm.org/D132412