[RISCV] Adjust RV64I data layout by using n32:64 in layout string

[craig.topper]

Summary

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of int or unsigned int.

If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.

[asb]

Thanks - I don't think much thought has gone into whether n32:n64 would be reasonable for RV64, so I really appreciate you digging in to it.

I've only run this against the GCC torture suite, and on average this seems to be about neutral (or mildly positive). There are a few cases where code is worse though. Here's a rather surprising example (I haven't investigated any further):

--- a/output_rv64imafdc_lp64_O1/930921-1.s
+++ b/output_rv64imafdc_lp64_O1/930921-1.s
@@ -24,18 +24,29 @@ main:                                   # @main
 # %bb.0:                                # %entry
        addi    sp, sp, -16
        sd      ra, 8(sp)                       # 8-byte Folded Spill
+       li      a0, 0
        li      a1, 0
-       li      a0, 1
-       lui     a2, 2
-       addiw   a2, a2, 1806
+       lui     a2, 699051
+       addiw   a2, a2, -1365
+       slli    a6, a2, 32
+       lui     a3, 171
+       addiw   a3, a3, -1365
+       slli    a3, a3, 12
+       addi    a3, a3, -1365
+       lui     a4, 2
+       addiw   a4, a4, 1808
 .LBB1_1:                                # %for.body
                                         # =>This Inner Loop Header: Depth=1
-       beqz    a0, .LBB1_4
+       srli    a5, a0, 33
+       slli    a2, a1, 32
+       mulhu   a2, a2, a6
+       srli    a2, a2, 33
+       bne     a2, a5, .LBB1_4
 # %bb.2:                                # %for.cond
                                         #   in Loop: Header=BB1_1 Depth=1
-       sext.w  a3, a1
        addiw   a1, a1, 1
-       bgeu    a2, a3, .LBB1_1
+       add     a0, a0, a3
+       bne     a1, a4, .LBB1_1
 # %bb.3:                                # %for.end
        li      a0, 0
        call    exit

[jrtc27]

That's trying to do return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1; for a range of x. Presumably the issue is MULW exists but not MULWHU and friends.

[jrtc27]

The DataLayout documentation says:

This specifies a set of native integer widths for the target CPU in bits. For example, it might contain n32 for 32-bit PowerPC, n32:64 for PowerPC 64, or n8:16:32:64 for X86-64. Elements of this set are considered to support most general arithmetic operations efficiently.

It's unclear what exactly that means for RISC-V.

Having said that, for the IVUsers example pointed out, that's just bad code in LLVM, it should permit things that are smaller than native integers, I would imagine. Otherwise, say, i16, won't be used on most targets (other than X86 and a few experimental, embedded or graphics-y targets) as they'll only have n32:64, but the comment there is clearly to just stop it creating overly-large integer types.

[craig.topper]

I believe there are two checks for DataLayout.isLegalInteger in IndVarSimplify that are interesting as well.

[jrtc27]

Possibly also SROA's, though probably unlikely to matter much as it'd be such a tiny aggregate

[craig.topper]

This will probably require something in AutoUpgrade.cpp to fix up old IR files. I think maybe X86 does an upgrade for some address space additions.

[craig.topper]

In D116735#3225286, @jrtc27 wrote:

That's trying to do return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1; for a range of x. Presumably the issue is MULW exists but not MULWHU and friends.

So the f function gets inlined into this compare f (i) != i / 3. The i/3 gets optimized by SelectionDAG into (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1. Before this patch, the automatic CSE in SelectionDAG merges this with the code from the inlined function. This makes a the comparison be statically always true so all the code gets optimized away.

With this patch, LSR kicks in and rewrites some of the inlined code from f by removing the multiply with 0xAAAAAAAB in favor of a modified induction variable that increments by 0xAAAAAAAB on each iteration. Now there's nothing for the div by constant optimization to CSE with so the comparison doesn't become statically always true.

I don't think this test is a blocker for this patch.

[joshua-arch1]

I have checked all the benchmarks.
For coremark, spec2006_int-471.omnetpp and eembc_networking_pktflow, the performance can improve by more than 3%, without degression of other cases.

[craig.topper]

In D116735#3230281, @joshua-arch1 wrote:

I have checked all the benchmarks.
For coremark, spec2006_int-471.omnetpp and eembc_networking_pktflow, the performance can improve by more than 3%, without degression of other cases.

Can you say more about what hardware and ISA extensions were used for that testing?

[joshua-arch1]

In D116735#3238854, @craig.topper wrote:

In D116735#3230281, @joshua-arch1 wrote:

I have checked all the benchmarks.
For coremark, spec2006_int-471.omnetpp and eembc_networking_pktflow, the performance can improve by more than 3%, without degression of other cases.

Can you say more about what hardware and ISA extensions were used for that testing?

I used T-HEAD XuanTie C906 processor based on the RV64GCV instruction set and THEAD instruction extension.

[joshua-arch1]

For the following benchmark, the performance can improve without degression of other cases (on T-HEAD XuanTie C906 processor with THEAD instruction extension)

spec2006_int-471.omnetpp	+18.9672%
spec2006_int-483.xalancbmk	+3.5192%
coremark	+3.8695%
eembc_networking_pktflowb1m	+4.1295%
eembc_networking_pktflowb2m	+4.5903%
eembc_networking_pktflowb4m	+4.0367%
eembc_networking_pktflowb512k	+5.2104%

Can you test on your hardware?

[joshua-arch1]

Ping.

[craig.topper]

In D116735#3247378, @joshua-arch1 wrote:

In D116735#3238854, @craig.topper wrote:

In D116735#3230281, @joshua-arch1 wrote:

I have checked all the benchmarks.
For coremark, spec2006_int-471.omnetpp and eembc_networking_pktflow, the performance can improve by more than 3%, without degression of other cases.

Can you say more about what hardware and ISA extensions were used for that testing?

I used T-HEAD XuanTie C906 processor based on the RV64GCV instruction set and THEAD instruction extension.

Was it tested using a version of LLVM that supports the THEAD instruction extension or just the public LLVM?

[zixuan-wu]

In D116735#3225715, @craig.topper wrote:

In D116735#3225286, @jrtc27 wrote:

That's trying to do return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1; for a range of x. Presumably the issue is MULW exists but not MULWHU and friends.

So the f function gets inlined into this compare f (i) != i / 3. The i/3 gets optimized by SelectionDAG into (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1. Before this patch, the automatic CSE in SelectionDAG merges this with the code from the inlined function. This makes a the comparison be statically always true so all the code gets optimized away.

With this patch, LSR kicks in and rewrites some of the inlined code from f by removing the multiply with 0xAAAAAAAB in favor of a modified induction variable that increments by 0xAAAAAAAB on each iteration. Now there's nothing for the div by constant optimization to CSE with so the comparison doesn't become statically always true.

I don't think this test is a blocker for this patch.

Does the patch improve performance absolutely in theory?
Could anybody else also test to see if the patch can improve performance because guys may have different environment or benchmarks?

[asb]

I think I'm correct in thinking that everyone so far is broadly in favour of this change, but as Craig suggests it likely wants something in AutoUpgrade.cpp to handle the change.

Does anyone feel differently?

[joshua-arch1]

Ping.

[joshua-arch1]

In D116735#3326135, @asb wrote:

I think I'm correct in thinking that everyone so far is broadly in favour of this change, but as Craig suggests it likely wants something in AutoUpgrade.cpp to handle the change.

Does anyone feel differently?

I have updated this patch by doing an upgrade for RISCV in AutoUpgrade.cpp to fix up old IR files. Could anyone review again?

[jrtc27]

llvm/lib/IR/AutoUpgrade.cpp

4583

Don't hard-code the data layout, replace the -n64- with -n32:64-, otherwise it's a pain for downstreams like us who change the data layout depending on both the ISA and the ABI. All the other examples in this function (which aren't visible here because you uploaded a diff without context... don't do that) avoid hard-coding data layouts so you have plenty of different examples to copy from.

[craig.topper]

Reverse ping.

[joshua-arch1]

In D116735#3417888, @craig.topper wrote:

Reverse ping.

Sorry for the delay. The patch has been updated by replacing the '-n64-' with '-n32:64-' for RISCV in AutoUpgrade.cpp.

[jrtc27]

llvm/lib/IR/AutoUpgrade.cpp

4850

Comment?

llvm/test/CodeGen/RISCV/rvv/fixed-vector-strided-load-store.ll

1077 ↗

(On Diff #419676)

This is a regression

llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp

35

Comment like AMDGPU?

[craig.topper]

llvm/test/CodeGen/RISCV/rvv/fixed-vector-strided-load-store.ll

1081 ↗

(On Diff #419712)

This move is interesting. I'll look closer at that.

[craig.topper]

llvm/test/CodeGen/RISCV/rvv/fixed-vector-strided-load-store.ll

1081 ↗

(On Diff #419712)

D122933 should fix the mv here.

1077 ↗

(On Diff #419676)

This does save an add inside the loop.

[craig.topper]

I'm seeing a regression on 401.bzip2 and possibly 471.astar. And I'm not seeing large improvements on 471.omnetpp or 483.xalancbmk.

[craig.topper]

Rebase.

[craig.topper]

Use TT.isRISCV64() in AutoUpgrade.cpp

[craig.topper]

Add requested comment to test.

[craig.topper]

Ping

[zixuan-wu]

In D116735#3429850, @craig.topper wrote:

I'm seeing a regression on 401.bzip2 and possibly 471.astar. And I'm not seeing large improvements on 471.omnetpp or 483.xalancbmk.

LGTM. But do you still get regression on spec? Or any improvements?

[craig.topper]

In D116735#3857705, @zixuan-wu wrote:

In D116735#3429850, @craig.topper wrote:

I'm seeing a regression on 401.bzip2 and possibly 471.astar. And I'm not seeing large improvements on 471.omnetpp or 483.xalancbmk.

LGTM. But do you still get regression on spec? Or any improvements?

I only have numbers from my downstream repo which has a bunch of other changes. For one of our CPUs, I'm now seeing improvements, and another looks neutral. So I think we should move forward this. If there are individual regressions we can work on fixing those by improving the backend or fixing cost models or whatever.

[reames]

Just want to note that I have no strong opinion on this patch. It doesn't seem unreasonable, and I'm comfortable with this being an empirically driven decision.

[frasercrmck]

I agree with @reames, though I do think the patch description could use a rewrite.

[asb]

I've put it on the agenda for the call today so we can close this off (I figure given it's been sitting so long, waiting a few extra days to cover it in the call is no big deal). But if the data shows this overall improves things, I think it's a sensible change to make.

[asb]

There were no objections on the call. Looks good to me - two minor changes before landing that would make sense:

• Fraser suggested tweaking the patch description
• Probably worth adding this to docs/ReleaseNotes.rst (I know we're not very consistent about doing this, but adding it now minimises the risk I miss it later!).

[craig.topper]

Add to release notes

[arichardson]

llvm/docs/ReleaseNotes.rst

122

Without additional context I don't think this makes much sense to most readers. Before looking at this patch description I would not have been and to say what n is used for.

Maybe something like "i32 has been marked as a legal integer type for RV64, improving code generation for some benchmarks"?

[jrtc27]

llvm/docs/ReleaseNotes.rst

122

"native integer type" not "legal integer type"; it still gets legalised during ISel

[craig.topper]

Refine ReleaseNotes

[frasercrmck]

LGTM other than a nit, but I concur that a comment in AutoUpgrade would be nice.

llvm/docs/ReleaseNotes.rst

123

something like , among other optimizations to avoid full stop + "and"?

clang/lib/Basic/Targets/RISCV.h

public:
   }
 };
 class LLVM_LIBRARY_VISIBILITY RISCV64TargetInfo : public RISCVTargetInfo {
 public:
   RISCV64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
       : RISCVTargetInfo(Triple, Opts) {
     LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
     IntMaxType = Int64Type = SignedLong;
-    resetDataLayout("e-m:e-p:64:64-i64:64-i128:128-n64-S128");
+    resetDataLayout("e-m:e-p:64:64-i64:64-i128:128-n32:64-S128");
   }
 
   bool setABI(const std::string &Name) override {
     if (Name == "lp64" || Name == "lp64f" || Name == "lp64d") {
       ABI = Name;
       return true;
     }
     return false;

llvm/docs/ReleaseNotes.rst

 
 * ...
 
 Changes to the RISC-V Backend
 -----------------------------
 
 * Support for the unratified Zbe, Zbf, Zbm, Zbp, Zbr, and Zbt extensions have
   been removed.
+* i32 is now a native type in the datalayout string. This enables
+  LoopStrengthReduce for loops with i32 induction variables, among other
+  optimizations.
 
 Changes to the WebAssembly Backend
 ----------------------------------
 
 * ...
 
 Changes to the Windows Target
 -----------------------------

llvm/lib/IR/AutoUpgrade.cpp

 bool llvm::UpgradeModuleFlags(Module &M) {
   NamedMDNode *ModFlags = M.getModuleFlagsMetadata();
   if (!ModFlags)
     return false;
 
   bool HasObjCFlag = false, HasClassProperties = false, Changed = false;
   bool HasSwiftVersionFlag = false;
   uint8_t SwiftMajorVersion, SwiftMinorVersion;
   uint32_t SwiftABIVersion;
   auto Int8Ty = Type::getInt8Ty(M.getContext());
   auto Int32Ty = Type::getInt32Ty(M.getContext());
 
   for (unsigned I = 0, E = ModFlags->getNumOperands(); I != E; ++I) {
     MDNode *Op = ModFlags->getOperand(I);
     if (Op->getNumOperands() != 3)
       continue;
     MDString *ID = dyn_cast_or_null<MDString>(Op->getOperand(1));

 std::string llvm::UpgradeDataLayoutString(StringRef DL, StringRef TT) {
   Triple T(TT);
   // For AMDGPU we uprgrade older DataLayouts to include the default globals
   // address space of 1.
   if (T.isAMDGPU() && !DL.contains("-G") && !DL.startswith("G")) {
     return DL.empty() ? std::string("G1") : (DL + "-G1").str();
   }
 
+  if (T.isRISCV64()) {
+    // Make i32 a native type for 64-bit RISC-V.
+    auto I = DL.find("-n64-");
+    if (I != StringRef::npos)
+      return (DL.take_front(I) + "-n32:64-" + DL.drop_front(I + 5)).str();
+    return DL.str();
+  }
+
   std::string Res = DL.str();
   if (!T.isX86())
     return Res;
 
   // If the datalayout matches the expected format, add pointer size address
   // spaces to the datalayout.
   std::string AddrSpaces = "-p270:32:32-p271:32:32-p272:64:64";
   if (!DL.contains(AddrSpaces)) {

llvm/lib/Target/RISCV/RISCVTargetMachine.cpp

extern "C" LLVM_EXTERNAL_VISIBILITY void LLVMInitializeRISCVTarget() {
   initializeRISCVSExtWRemovalPass(*PR);
   initializeRISCVPreRAExpandPseudoPass(*PR);
   initializeRISCVExpandPseudoPass(*PR);
   initializeRISCVInsertVSETVLIPass(*PR);
 }
 
 static StringRef computeDataLayout(const Triple &TT) {
   if (TT.isArch64Bit())
-    return "e-m:e-p:64:64-i64:64-i128:128-n64-S128";
+    return "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128";
   assert(TT.isArch32Bit() && "only RV32 and RV64 are currently supported");
   return "e-m:e-p:32:32-i64:64-n32-S128";
 }
 
 static Reloc::Model getEffectiveRelocModel(const Triple &TT,
                                            Optional<Reloc::Model> RM) {
   return RM.value_or(Reloc::Static);
 }

llvm/test/CodeGen/RISCV/aext-to-sext.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -mtriple=riscv64 -verify-machineinstrs < %s \
 ; RUN:   | FileCheck %s -check-prefix=RV64I
 
 ; Make sure we don't generate an addi in the loop in
 ; addition to the addiw. Previously we type legalize the
 ; setcc use using signext and the phi use using anyext.
 ; We now detect when it would be beneficial to replace
 ; anyext with signext.
 
 define void @quux(i32 signext %arg, i32 signext %arg1) nounwind {
 ; RV64I-LABEL: quux:
 ; RV64I:       # %bb.0: # %bb
-; RV64I-NEXT:    addi sp, sp, -32
-; RV64I-NEXT:    sd ra, 24(sp) # 8-byte Folded Spill
-; RV64I-NEXT:    sd s0, 16(sp) # 8-byte Folded Spill
-; RV64I-NEXT:    sd s1, 8(sp) # 8-byte Folded Spill
+; RV64I-NEXT:    addi sp, sp, -16
+; RV64I-NEXT:    sd ra, 8(sp) # 8-byte Folded Spill
+; RV64I-NEXT:    sd s0, 0(sp) # 8-byte Folded Spill
 ; RV64I-NEXT:    beq a0, a1, .LBB0_3
 ; RV64I-NEXT:  # %bb.1: # %bb2.preheader
-; RV64I-NEXT:    mv s0, a1
-; RV64I-NEXT:    mv s1, a0
+; RV64I-NEXT:    subw s0, a1, a0
 ; RV64I-NEXT:  .LBB0_2: # %bb2
 ; RV64I-NEXT:    # =>This Inner Loop Header: Depth=1
 ; RV64I-NEXT:    call hoge@plt
-; RV64I-NEXT:    addiw s1, s1, 1
-; RV64I-NEXT:    bne s1, s0, .LBB0_2
+; RV64I-NEXT:    addiw s0, s0, -1
+; RV64I-NEXT:    bnez s0, .LBB0_2
 ; RV64I-NEXT:  .LBB0_3: # %bb6
-; RV64I-NEXT:    ld ra, 24(sp) # 8-byte Folded Reload
-; RV64I-NEXT:    ld s0, 16(sp) # 8-byte Folded Reload
-; RV64I-NEXT:    ld s1, 8(sp) # 8-byte Folded Reload
-; RV64I-NEXT:    addi sp, sp, 32
+; RV64I-NEXT:    ld ra, 8(sp) # 8-byte Folded Reload
+; RV64I-NEXT:    ld s0, 0(sp) # 8-byte Folded Reload
+; RV64I-NEXT:    addi sp, sp, 16
 ; RV64I-NEXT:    ret
 bb:
   %tmp = icmp eq i32 %arg, %arg1
   br i1 %tmp, label %bb6, label %bb2
 
 bb2:                                              ; preds = %bb2, %bb
   %tmp3 = phi i32 [ %tmp4, %bb2 ], [ %arg, %bb ]
   tail call void @hoge()

llvm/test/CodeGen/RISCV/loop-strength-reduce-add-cheaper-than-mul.ll

 ; RV32-NEXT:    sb zero, 0(a4)
 ; RV32-NEXT:    blt a1, a3, .LBB0_2
 ; RV32-NEXT:  .LBB0_3: # %return
 ; RV32-NEXT:    ret
 ;
 ; RV64-LABEL: test:
 ; RV64:       # %bb.0: # %entry
 ; RV64-NEXT:    slliw a1, a0, 1
-; RV64-NEXT:    lui a4, 2
-; RV64-NEXT:    blt a4, a1, .LBB0_3
+; RV64-NEXT:    lui a3, 2
+; RV64-NEXT:    blt a3, a1, .LBB0_3
 ; RV64-NEXT:  # %bb.1: # %bb.preheader
-; RV64-NEXT:    li a2, 0
-; RV64-NEXT:    lui a3, %hi(flags2)
-; RV64-NEXT:    addi a3, a3, %lo(flags2)
-; RV64-NEXT:    addiw a4, a4, 1
+; RV64-NEXT:    lui a2, %hi(flags2)
+; RV64-NEXT:    addi a2, a2, %lo(flags2)
+; RV64-NEXT:    addiw a3, a3, 1
 ; RV64-NEXT:  .LBB0_2: # %bb
 ; RV64-NEXT:    # =>This Inner Loop Header: Depth=1
-; RV64-NEXT:    mulw a5, a2, a0
-; RV64-NEXT:    addw a5, a5, a1
-; RV64-NEXT:    slli a6, a5, 32
-; RV64-NEXT:    srli a6, a6, 32
-; RV64-NEXT:    add a6, a3, a6
-; RV64-NEXT:    sb zero, 0(a6)
-; RV64-NEXT:    addw a5, a5, a0
-; RV64-NEXT:    addiw a2, a2, 1
-; RV64-NEXT:    blt a5, a4, .LBB0_2
+; RV64-NEXT:    slli a4, a1, 32
+; RV64-NEXT:    srli a4, a4, 32
+; RV64-NEXT:    add a4, a2, a4
+; RV64-NEXT:    addw a1, a1, a0
+; RV64-NEXT:    sb zero, 0(a4)
+; RV64-NEXT:    blt a1, a3, .LBB0_2
 ; RV64-NEXT:  .LBB0_3: # %return
 ; RV64-NEXT:    ret
 entry:
   %k_addr.012 = shl i32 %i, 1
   %tmp14 = icmp sgt i32 %k_addr.012, 8192
   br i1 %tmp14, label %return, label %bb
 
 bb:

llvm/test/CodeGen/RISCV/loop-strength-reduce-loop-invar.ll

 ; RV32-NEXT:    bnez a1, .LBB0_2
 ; RV32-NEXT:  .LBB0_3: # %return
 ; RV32-NEXT:    ret
 ;
 ; RV64-LABEL: test:
 ; RV64:       # %bb.0: # %entry
 ; RV64-NEXT:    blez a1, .LBB0_3
 ; RV64-NEXT:  # %bb.1: # %cond_true.preheader
-; RV64-NEXT:    li a4, 0
+; RV64-NEXT:    li a2, 0
 ; RV64-NEXT:    slli a0, a0, 6
-; RV64-NEXT:    lui a2, %hi(A)
-; RV64-NEXT:    addi a2, a2, %lo(A)
-; RV64-NEXT:    add a0, a2, a0
-; RV64-NEXT:    li a2, 4
-; RV64-NEXT:    li a3, 5
+; RV64-NEXT:    lui a3, %hi(A)
+; RV64-NEXT:    addi a3, a3, %lo(A)
+; RV64-NEXT:    add a0, a3, a0
+; RV64-NEXT:    addi a3, a0, 4
+; RV64-NEXT:    li a4, 4
+; RV64-NEXT:    li a5, 5
 ; RV64-NEXT:  .LBB0_2: # %cond_true
 ; RV64-NEXT:    # =>This Inner Loop Header: Depth=1
-; RV64-NEXT:    addiw a5, a4, 1
-; RV64-NEXT:    slli a6, a5, 2
+; RV64-NEXT:    sw a4, 0(a3)
+; RV64-NEXT:    addiw a6, a2, 2
+; RV64-NEXT:    slli a6, a6, 2
 ; RV64-NEXT:    add a6, a0, a6
-; RV64-NEXT:    sw a2, 0(a6)
-; RV64-NEXT:    addiw a4, a4, 2
-; RV64-NEXT:    slli a4, a4, 2
-; RV64-NEXT:    add a4, a0, a4
-; RV64-NEXT:    sw a3, 0(a4)
-; RV64-NEXT:    mv a4, a5
-; RV64-NEXT:    bne a5, a1, .LBB0_2
+; RV64-NEXT:    sw a5, 0(a6)
+; RV64-NEXT:    addiw a2, a2, 1
+; RV64-NEXT:    addi a3, a3, 4
+; RV64-NEXT:    bne a1, a2, .LBB0_2
 ; RV64-NEXT:  .LBB0_3: # %return
 ; RV64-NEXT:    ret
 entry:
   %N = bitcast i32 %N.in to i32
   %tmp5 = icmp sgt i32 %N.in, 0
   br i1 %tmp5, label %cond_true, label %return
 
 cond_true:

llvm/test/CodeGen/RISCV/rvv/fixed-vector-strided-load-store-asm.ll

 ; CHECK-NEXT:    vse8.v v8, (a2)
 ; CHECK-NEXT:    addi t1, t1, -32
 ; CHECK-NEXT:    addi a2, a2, 32
 ; CHECK-NEXT:    addi a6, a6, 160
 ; CHECK-NEXT:    bnez t1, .LBB12_3
 ; CHECK-NEXT:  # %bb.4:
 ; CHECK-NEXT:    beq a4, a5, .LBB12_7
 ; CHECK-NEXT:  .LBB12_5:
-; CHECK-NEXT:    slli a2, a3, 2
-; CHECK-NEXT:    add a2, a2, a3
-; CHECK-NEXT:    add a1, a1, a2
-; CHECK-NEXT:    li a2, 1024
+; CHECK-NEXT:    addiw a2, a3, -1024
+; CHECK-NEXT:    add a0, a0, a3
+; CHECK-NEXT:    slli a4, a3, 2
+; CHECK-NEXT:    add a3, a4, a3
+; CHECK-NEXT:    add a1, a1, a3
 ; CHECK-NEXT:  .LBB12_6: # =>This Inner Loop Header: Depth=1
-; CHECK-NEXT:    lb a4, 0(a1)
-; CHECK-NEXT:    add a5, a0, a3
-; CHECK-NEXT:    lb a6, 0(a5)
-; CHECK-NEXT:    addw a4, a6, a4
-; CHECK-NEXT:    sb a4, 0(a5)
-; CHECK-NEXT:    addiw a4, a3, 1
-; CHECK-NEXT:    addi a3, a3, 1
+; CHECK-NEXT:    lb a3, 0(a1)
+; CHECK-NEXT:    lb a4, 0(a0)
+; CHECK-NEXT:    addw a3, a4, a3
+; CHECK-NEXT:    sb a3, 0(a0)
+; CHECK-NEXT:    addiw a2, a2, 1
+; CHECK-NEXT:    addi a0, a0, 1
 ; CHECK-NEXT:    addi a1, a1, 5
-; CHECK-NEXT:    bne a4, a2, .LBB12_6
+; CHECK-NEXT:    bnez a2, .LBB12_6
 ; CHECK-NEXT:  .LBB12_7:
 ; CHECK-NEXT:    ret
   %4 = icmp eq i32 %2, 1024
   br i1 %4, label %36, label %5
 
 5:                                                ; preds = %3
   %6 = sext i32 %2 to i64
   %7 = sub i32 1023, %2

llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll

 ; RV32-NEXT:    ret
 ;
 ; RV64-LABEL: splat_load_licm:
 ; RV64:       # %bb.0:
 ; RV64-NEXT:    lui a1, %hi(.LCPI12_0)
 ; RV64-NEXT:    addi a1, a1, %lo(.LCPI12_0)
 ; RV64-NEXT:    vsetivli zero, 4, e32, m1, ta, ma
 ; RV64-NEXT:    vlse32.v v8, (a1), zero
-; RV64-NEXT:    li a1, 0
-; RV64-NEXT:    li a2, 1024
+; RV64-NEXT:    li a1, 1024
 ; RV64-NEXT:  .LBB12_1: # =>This Inner Loop Header: Depth=1
-; RV64-NEXT:    slli a3, a1, 2
-; RV64-NEXT:    add a3, a0, a3
-; RV64-NEXT:    addiw a1, a1, 4
-; RV64-NEXT:    vse32.v v8, (a3)
-; RV64-NEXT:    bne a1, a2, .LBB12_1
+; RV64-NEXT:    vse32.v v8, (a0)
+; RV64-NEXT:    addiw a1, a1, -4
+; RV64-NEXT:    addi a0, a0, 16
+; RV64-NEXT:    bnez a1, .LBB12_1
 ; RV64-NEXT:  # %bb.2:
 ; RV64-NEXT:    ret
   br label %2
 
 2:                                                ; preds = %2, %1
   %3 = phi i32 [ 0, %1 ], [ %6, %2 ]
   %4 = getelementptr inbounds float, float* %0, i32 %3
   %5 = bitcast float* %4 to <4 x float>*
   store <4 x float> <float 3.000000e+00, float 3.000000e+00, float 3.000000e+00, float 3.000000e+00>, <4 x float>* %5, align 4
   %6 = add nuw i32 %3, 4
   %7 = icmp eq i32 %6, 1024
   br i1 %7, label %8, label %2
 
 8:                                                ; preds = %2
   ret void
 }

llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp

TEST(DataLayoutUpgradeTest, ValidDataLayoutUpgrade) {
   EXPECT_EQ(DL2, "e-m:w-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64"
                  "-f80:128-n8:16:32-S32");
   EXPECT_EQ(DL3, "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128"
                  "-n32:64-S128");
 
   // Check that AMDGPU targets add -G1 if it's not present.
   EXPECT_EQ(UpgradeDataLayoutString("e-p:32:32", "r600"), "e-p:32:32-G1");
   EXPECT_EQ(UpgradeDataLayoutString("e-p:64:64", "amdgcn"), "e-p:64:64-G1");
+
+  // Check that RISCV64 upgrades -n64 to -n32:64.
+  EXPECT_EQ(UpgradeDataLayoutString("e-m:e-p:64:64-i64:64-i128:128-n64-S128",
+                                    "riscv64"),
+            "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128");
 }
 
 TEST(DataLayoutUpgradeTest, NoDataLayoutUpgrade) {
   std::string DL1 = UpgradeDataLayoutString(
       "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32"
       "-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
       "-n8:16:32:64-S128",
       "x86_64-unknown-linux-gnu");