sext(square nsw) produces unnecessary zext on riscv64/mips64/loongarch64

[sorear]

Minimal C reproducer(s):

int a(int x) { return x*x; }
long b(int x) { return x*x; }

Expected output (on riscv64, generated with -fwrapv):

a:                                      # @a
        mulw    a0, a0, a0
        ret

What is actually generated:

a:                                      # @a
        mulw    a0, a0, a0
        slli    a0, a0, 32
        srli    a0, a0, 32
        ret

compiler explorer link: https://godbolt.org/z/Yq898xoT1. Clang 14 produces the optimal code for a but not for b.

[Endilll]

Reproduces on post-17 trunk with -O3 as well: https://godbolt.org/z/sKWGozjPh

[llvmbot]

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

Minimal C reproducer(s):

int a(int x) { return x*x; }
long b(int x) { return x*x; }

Expected output (on riscv64, generated with -fwrapv):

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        ret

What is actually generated:

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        slli    a0, a0, 32
        srli    a0, a0, 32
        ret

compiler explorer link: https://godbolt.org/z/Yq898xoT1. Clang 14 produces the optimal code for a but not for b.

[dtcxzyw]

Partially fixed by #65984. I am working on the middle-end part.

[dtcxzyw]

@topperc @nikic @goldsteinn @preames
Should we introduce an anyext IR node? We can replace sext/zext with anyext when the sign bit is known to be 0 or the high bits are not demanded.

There are some benefits from anyext:

1. Exploit more optimization opportunities
2. Simplify ISel since we have ANYEXT and G_ANYEXT in CodeGen

See also:
https://discourse.llvm.org/t/aggressive-conversion-of-sext-to-zext-blocks-indvarsimplify/61561
https://discourse.llvm.org/t/shift-by-signext-sext-is-bad-for-analysis-ignore-its-use-count/53204

[nikic]

See https://reviews.llvm.org/D156444 for the correct solution to this problem.

[dtcxzyw]

It should be addressed by #67982 and follow-up PRs.

[dtcxzyw]

It has been addressed on the RISC-V backend.

[llvmbot]

@llvm/issue-subscribers-backend-mips

Author: sorear (sorear)

Minimal C reproducer(s):

int a(int x) { return x*x; }
long b(int x) { return x*x; }

Expected output (on riscv64, generated with -fwrapv):

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        ret

What is actually generated:

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        slli    a0, a0, 32
        srli    a0, a0, 32
        ret

compiler explorer link: https://godbolt.org/z/Yq898xoT1. Clang 14 produces the optimal code for a but not for b.

[llvmbot]

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

Author: sorear (sorear)

Minimal C reproducer(s):

int a(int x) { return x*x; }
long b(int x) { return x*x; }

Expected output (on riscv64, generated with -fwrapv):

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        ret

What is actually generated:

a:                                      # @<!-- -->a
        mulw    a0, a0, a0
        slli    a0, a0, 32
        srli    a0, a0, 32
        ret

compiler explorer link: https://godbolt.org/z/Yq898xoT1. Clang 14 produces the optimal code for a but not for b.

[Endilll]

@dtcxzyw IIUC RISC-V backend was affected by this, so we should keep the corresponding label, even though it's been addressed.