Missed optimization on in-order RISC-V

[chadaustin]

I've observed situations where clang and rustc will generate suboptimal code for in-order RISC-V cores that support multiple parallel loads.

In general, as many clobbered temporary registers as possible should be used to hoist loads before any instructions that use them.

C:

void inc2(int* __restrict a, int* __restrict b, int* __restrict c, int* __restrict d)
{
    (*a)++;
    (*b)++;
    (*c)++;
    (*d)++;
}

rv64gc gcc:

inc2(int*, int*, int*, int*):
        lw      a7,0(a0)
        lw      a6,0(a1)
        lw      a4,0(a2)
        lw      a5,0(a3)
        addiw   a7,a7,1
        addiw   a6,a6,1
        addiw   a4,a4,1
        addiw   a5,a5,1
        sw      a7,0(a0)
        sw      a6,0(a1)
        sw      a4,0(a2)
        sw      a5,0(a3)
        ret

rv64gc clang:

inc2(int*, int*, int*, int*):
        lw      a4, 0(a0)
        lw      a5, 0(a1)
        addi    a4, a4, 1
        sw      a4, 0(a0)
        lw      a0, 0(a2)
        lw      a4, 0(a3)
        addi    a5, a5, 1
        sw      a5, 0(a1)
        addi    a0, a0, 1
        addi    a4, a4, 1
        sw      a0, 0(a2)
        sw      a4, 0(a3)
        ret

You can see the same issue in rustc's output: https://gcc.godbolt.org/z/b8na96EhW

I apologize if duplicate - could not find another issue about this.

[llvmbot]

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

Author: Chad Austin (chadaustin)

I've observed situations where clang and rustc will generate suboptimal code for in-order RISC-V cores that support multiple parallel loads.

In general, as many clobbered temporary registers as possible should be used to hoist loads before any instructions that use them.

C:

void inc2(int* __restrict a, int* __restrict b, int* __restrict c, int* __restrict d)
{
    (*a)++;
    (*b)++;
    (*c)++;
    (*d)++;
}

rv64gc gcc:

inc2(int*, int*, int*, int*):
        lw      a7,0(a0)
        lw      a6,0(a1)
        lw      a4,0(a2)
        lw      a5,0(a3)
        addiw   a7,a7,1
        addiw   a6,a6,1
        addiw   a4,a4,1
        addiw   a5,a5,1
        sw      a7,0(a0)
        sw      a6,0(a1)
        sw      a4,0(a2)
        sw      a5,0(a3)
        ret

rv64gc clang:

inc2(int*, int*, int*, int*):
        lw      a4, 0(a0)
        lw      a5, 0(a1)
        addi    a4, a4, 1
        sw      a4, 0(a0)
        lw      a0, 0(a2)
        lw      a4, 0(a3)
        addi    a5, a5, 1
        sw      a5, 0(a1)
        addi    a0, a0, 1
        addi    a4, a4, 1
        sw      a0, 0(a2)
        sw      a4, 0(a3)
        ret

You can see the same issue in rustc's output: https://gcc.godbolt.org/z/b8na96EhW

I apologize if duplicate - could not find another issue about this.

[chadaustin]

It appears that in-order ARMv7 might have the same issue: https://gcc.godbolt.org/z/3f3Y66KP6

[mikhailramalho]

Maybe it's a scheduler limitation? I'm working on a scheduler patch for the spacemit-x60 and I get:

~/tools/llvm-project/build/bin/clang -O3 -S 135860.c -target riscv64-arc-linux-gnu -mcpu=spacemit-x60 -o - 
	.attribute	4, 16
	.attribute	5, "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_b1p0_v1p0_zic64b1p0_zicbom1p0_zicbop1p0_zicboz1p0_ziccamoa1p0_ziccif1p0_zicclsm1p0_ziccrse1p0_zicntr2p0_zicond1p0_zicsr2p0_zifencei2p0_zihintpause2p0_zihpm2p0_zmmul1p0_za64rs1p0_zaamo1p0_zalrsc1p0_zfh1p0_zfhmin1p0_zca1p0_zcd1p0_zba1p0_zbb1p0_zbc1p0_zbkc1p0_zbs1p0_zkt1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvfh1p0_zvfhmin1p0_zvkt1p0_zvl128b1p0_zvl256b1p0_zvl32b1p0_zvl64b1p0_ssccptr1p0_sscofpmf1p0_sscounterenw1p0_sstc1p0_sstvala1p0_sstvecd1p0_svade1p0_svbare1p0_svinval1p0_svnapot1p0_svpbmt1p0"
	.file	"135860.c"
	.text
	.globl	inc2                            # -- Begin function inc2
	.p2align	1
	.type	inc2,@function
inc2:                                   # @inc2
	.cfi_startproc
# %bb.0:                                # %entry
	lw	a6, 0(a0)
	lw	a5, 0(a1)
	lw	a7, 0(a2)
	lw	a4, 0(a3)
	addi	a6, a6, 1
	addi	a5, a5, 1
	sw	a6, 0(a0)
	sw	a5, 0(a1)
	addi	a7, a7, 1
	addi	a4, a4, 1
	sw	a7, 0(a2)
	sw	a4, 0(a3)
	ret