[all-commits] [llvm/llvm-project] fc69f2: [RISCV] Convert LWU to LW if possible in RISCVOptW...
Alex Bradbury via All-commits
all-commits at lists.llvm.org
Mon Jul 21 03:48:54 PDT 2025
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: fc69f25a8f8c1bea9c7dbe1ce7597b3c0cafb122
https://github.com/llvm/llvm-project/commit/fc69f25a8f8c1bea9c7dbe1ce7597b3c0cafb122
Author: Alex Bradbury <asb at igalia.com>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M llvm/lib/Target/RISCV/RISCVOptWInstrs.cpp
M llvm/test/CodeGen/RISCV/GlobalISel/double-convert.ll
M llvm/test/CodeGen/RISCV/GlobalISel/float-convert.ll
M llvm/test/CodeGen/RISCV/GlobalISel/rv64zbb.ll
M llvm/test/CodeGen/RISCV/GlobalISel/rv64zbkb.ll
M llvm/test/CodeGen/RISCV/atomic-signext.ll
M llvm/test/CodeGen/RISCV/bfloat-convert.ll
M llvm/test/CodeGen/RISCV/double-convert-strict.ll
M llvm/test/CodeGen/RISCV/double-convert.ll
M llvm/test/CodeGen/RISCV/float-convert-strict.ll
M llvm/test/CodeGen/RISCV/float-convert.ll
M llvm/test/CodeGen/RISCV/half-convert-strict.ll
M llvm/test/CodeGen/RISCV/half-convert.ll
M llvm/test/CodeGen/RISCV/memcmp-optsize.ll
M llvm/test/CodeGen/RISCV/memcmp.ll
M llvm/test/CodeGen/RISCV/prefer-w-inst.mir
M llvm/test/CodeGen/RISCV/rv64zbb.ll
M llvm/test/CodeGen/RISCV/rv64zbkb.ll
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vwaddu.ll
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vwmulsu.ll
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vwmulu.ll
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vwsubu.ll
M llvm/test/CodeGen/RISCV/zdinx-boundary-check.ll
Log Message:
-----------
[RISCV] Convert LWU to LW if possible in RISCVOptWInstrs (#144703)
After the refactoring in #149710 the logic change is trivial.
Motivation for preferring sign-extended 32-bit loads (LW) vs
zero-extended (LWU):
* LW is compressible while LWU is not.
* Helps to minimise the diff vs RV32 (e.g. LWU vs LW)
* Helps to minimise distracting diffs vs GCC. I see this come up
frequently when comparing GCC code and in these cases it's a red
herring.
Similar normalisation could be done for LHU and LH, but this is less
well motivated as there is a compressed LHU (and if performing the
change in RISCVOptWInstrs it wouldn't be done for RV32). There is a
compressed LBU but not LB, meaning doing a similar normalisation for
byte-sized loads would actually be a regression in terms of code size.
Load narrowing when allowed by hasAllNBitUsers isn't explored in this
patch.
This changes ~20500 instructions in an RVA22 build of the
llvm-test-suite including SPEC 2017. As part of the review, the option
of doing the change at ISel time was explored but was found to be less
effective.
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list