[DAGCombiner] [CodeGenPrepare] Split large offsets from base addresses

[luismarques]

Summary

This patch addresses the following issue that came up in the context of RISC-V benchmarks, but which affects other targets. Suppose you have several loads/stores that access array elements or struct fields with large offsets:

void foo(int *x, int *y) {
    y[0] = x[0x10001];
    y[1] = x[0x10002];
    y[2] = x[0x10003];
    ...
}

In a target such as RISC-V you cannot add 0x10001 to the address of X in a single instruction (the constant doesn't fit the 12-bit signed immediate), so the generated code is more directly reflected by something like this:

void foo(int *x, int *y) {
    y[0] = *(x+0x10000+1);
    y[1] = *(x+0x10000+2);
    y[2] = *(x+0x10000+3);
    ...
}

But you can fold the +1, etc. into an immediate offset of the load/store instructions, so you are able to effectively have something like this:

void foo(int *x, int *y) {
    int *base = &x[0x10001];
    y[0] = base[0];
    y[1] = base[1];
    y[2] = base[2];
    ...
}

That optimization is only able to be performed, though, if the +1, +2, etc. are split from the 0x10000. Fortunately, there is already a target hook that indicates we want such an address split to occur: shouldConsiderGEPOffsetSplit. When that hook returns true, CodeGenPrepare.cpp adds the GEPs with large offsets to a list of GEPs to be split and ::splitLargeGEPOffsets splits them, in a process clearly illustrated in that method's comments. Unfortunately, the split currently only occurs when the base and the GEP are in different BBs, since the DAGCombiner would just recombine those in the same BB anyway.

This patch intends to:

1. make the split also occur in the cases where the base and the GEP are in the same BB (that's often the case);
2. ensure that the DAGCombiner doesn't reassociate them back again.

To achieve that second step the patch adds a check before the reassociation of add instructions to see if the sum is used by loads or stores and if reassociating could break a reg+imm addressing mode for those loads/stores. This strategy seems to work, as shown in the tests.

A possible alternative would be to add a RISC-V specific pass to split the addresses, but solving this problem in a more generic fashion is probably preferable, as it avoids duplication of functionality and can benefit other targets.

(It might be possible to address https://bugs.llvm.org/show_bug.cgi?id=24447 by making the address mode checks more stringent for X86, etc.)

[efriedma]

Should we care about the number of uses of N0 here? It should generally be "safe" to reassociate in cases where it only has one use.

Given that we're splitting the GEPs before SelectionDAG, the only way to preserve the optimization is to avoid re-merging them... and I can't think of any reasonable approach for that other than something along the lines of this patch. Well, I guess we could just completely disable folding without regard for whether the addressing mode is legal, but that probably interacts badly with type legalization.

The alternative, as you note, is to do something after isel. Arguably that would be more effective. At that point you have a better idea of what constants are actually necessary, and you could integrate it with other similar optimizations like optimizing related integer constants. This is sort of along the lines of RISCVMergeBaseOffset.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp

980

This computation of AccessTy is weird: it's supposed to be the type of the load, not the type of the pointer.

How you get the right access type is sort of awkward, of course... I guess you could traverse the use list.

[asb]

In D60294#1456609, @efriedma wrote:

Given that we're splitting the GEPs before SelectionDAG, the only way to preserve the optimization is to avoid re-merging them... and I can't think of any reasonable approach for that other than something along the lines of this patch. Well, I guess we could just completely disable folding without regard for whether the addressing mode is legal, but that probably interacts badly with type legalization.

The alternative, as you note, is to do something after isel. Arguably that would be more effective. At that point you have a better idea of what constants are actually necessary, and you could integrate it with other similar optimizations like optimizing related integer constants. This is sort of along the lines of RISCVMergeBaseOffset.

My feeling is that if there are no major objections to disabling the fold in this case (e.g. an undocumented requirement that add with constants are always canonicalised as they currently are), then it seems worth adding logic like this to disable the re-merging on the basis that 1) it's not a huge amount of code that serves to preserve work that's already done in CodeGenPrepare anyway, 2) it's easier for other backends to make use of it. I agree there may later be scope for pass that runs after ISel that might be wider in scope. But for this transformation, it seems a shame to have a situation where CodeGenPrepare does the necessary analysis+transformation, the DAGCombiner undoes that work, then a very similar analysis+transformation is done again on the SelectionDAG.

[asb]

lib/CodeGen/SelectionDAG/DAGCombiner.cpp

980

Traversing the use list as callers to canFoldInAddressingMode do seems sensible. This function can identify the first load/store operation and use the type from that. Bail out if none of the uses are load/stores. By doing this we can also get the right address space. It might be worth exploring if we can just call canFoldInAddressingMode rather than replicating similar logic here.

[lebedev.ri]

Passing-by comment: can/will this do anything to e.g. the testcase https://reviews.llvm.org/D59535#1458118 which resulted in revert if D59535 ?
The problem being solved here seems /related/.

[spatel]

Not sure if it's relevant to what this patch is trying to do, but x86 has a similar example described here:
https://bugs.llvm.org/show_bug.cgi?id=24447

[asb]

In D60294#1462628, @spatel wrote:

Not sure if it's relevant to what this patch is trying to do, but x86 has a similar example described here:
https://bugs.llvm.org/show_bug.cgi?id=24447

Thanks for the link. This has the potential to help in the case that the large constants were produced by getelementptrs. Except the logic here and in CodeGenPrepare's splitgep routines checks isLegalAddressingMode, which may not be selective enough for X86 given its addressing modes are so unrestricted.

[dmgreen]

Hello. This looks like an interesting patch. Thanks for working on it. I ran some numbers and on Thumb1 targets (where resources are generally very constrained) this looks like a nice improvement.

Things didn't look as good on Thumb2 (and AArch64), but that might be that something isn't tuned correctly, or something that's just going wrong. I'll try and take a look (in the morning). Don't feel that that should block you here, I think something odd might be going on with floating point constants in soft-fp? I'm not sure yet.

[luismarques]

In D60294#1463517, @dmgreen wrote:

Hello. This looks like an interesting patch. Thanks for working on it. I ran some numbers and on Thumb1 targets (where resources are generally very constrained) this looks like a nice improvement.
Things didn't look as good on Thumb2 (and AArch64), but that might be that something isn't tuned correctly, or something that's just going wrong. I'll try and take a look (in the morning). Don't feel that that should block you here, I think something odd might be going on with floating point constants in soft-fp? I'm not sure yet.

My reply through the email seems to have bounced, so I'm quoting it here:
Thanks for the feedback and encouragement. I'm finishing an improved version of the patch, it would be great if you could rerun those analyses on the updated version and share if it changes anything important. The new version properly checks if the transformation would impact the loads/stores that use the constants. I can see that check having an impact on some real-world scenarios not covered by the existing tests.

[luismarques]

The patch now checks if doing the reassociation could break any of the load/stores that use the added constants. The value type and addressing space is now obtained from the load/stores. The failing tests have been slightly reduced by these changes:

Failing Tests (5):

LLVM :: CodeGen/AMDGPU/salu-to-valu.ll
LLVM :: CodeGen/SystemZ/int-add-08.ll
LLVM :: CodeGen/SystemZ/int-sub-05.ll
LLVM :: CodeGen/ARM/misched-fusion-aes.ll
LLVM :: CodeGen/ARM/vector-spilling.ll

[luismarques]

In D60294#1456609, @efriedma wrote:

Should we care about the number of uses of N0 here? It should generally be "safe" to reassociate in cases where it only has one use.

Let's say we are doing *(x + 0x10000 + 2) and we don't use x + 0x10000 anywhere else (that's the N0, right?). In an arch like RISC-V if we want to add 0x10002 to x that takes two instructions to materialize the constant, while 0x10000 only takes one. We can avoid that second instruction by folding the +2 into the load/store. Am I thinking about this wrong?

[efriedma]

I wasn't thinking in terms of keeping the addressing mode legal, just avoiding destroying the work of constant hoisting. Constant hoisting won't split a constant in the way you're suggesting. And it's relatively easy to write patterns to split "load x+c" in the most efficient way if "c" has a single use. I guess the more restrictive version would allow splitting single-use constants as a DAGCombine, or earlier? Not sure why you'd want to, though.

[luismarques]

This updates the patch to:

1. Add a check for N0.hasOneUse(), as suggested by Eli Friedman;
2. Changes the shuffling indices of the ARM vector-spilling.ll test, to ensure the desired multi-register vector spills and restores are generated;
3. Updates the ARM misched-fusion-aes.ll AES fusion test checks to account for the new instruction scheduling. We still seem to have the desired number of fusable instructions, just in a different order.

Those two tests would remain broken even if you always gave the OK to reassociate in reassociationCanBreakAddressingModePattern. With these changes the remaining failing tests should be:

Failing Tests (3):

LLVM :: CodeGen/AMDGPU/salu-to-valu.ll
LLVM :: CodeGen/SystemZ/int-sub-05.ll
LLVM :: CodeGen/SystemZ/int-add-08.ll

I'll look more closely into those tests. If necessary we can tweak the reassociation gating for those.

[luismarques]

Fix the remaining failing unit tests (for AMDGPU and SystemZ).

[uweigand]

Those test case changes represent an actual improvement here, so this looks good. Thanks!

test/CodeGen/SystemZ/int-add-08.ll

53 ↗

(On Diff #196024)

It would be preferable to keep verifying the base register here, i.e.

lay [[BASE::%r[1-5]]], 524280(%1)
alg {{%r[0-5]}}, 8([[BASE]])

test/CodeGen/SystemZ/int-sub-05.ll

58 ↗

(On Diff #196024)

Same here.

[dmgreen]

With rL358845 in, the remaining results I ran look good. Consider us out of your way.

[luismarques]

• Fixes a minor whitespace issue;
• Updates the SystemZ tests to preserve the base register check;
• Updates the summary to reflect the current patch/review status.

Thanks for the review comments!

[luismarques]

In D60294#1476116, @dmgreen wrote:

With rL358845 in, the remaining results I ran look good. Consider us out of your way.

Great! Thanks for looking into this.

[uweigand]

test/CodeGen/SystemZ/int-sub-05.ll

58 ↗

(On Diff #196413)

Should be %r[1-5] here as well, register 0 cannot be used for address generation. Otherwise, the SystemZ changes LGTM now. Thanks!

[luismarques]

• Fix SystemZ's int-sub-05.ll test register matching.

[luismarques]

test/CodeGen/SystemZ/int-sub-05.ll

58 ↗

(On Diff #196413)

Oops. Thanks!

[uweigand]

test/CodeGen/SystemZ/int-sub-05.ll

58 ↗

(On Diff #196413)

Perfect, thanks!

[luismarques]

Rebased on master.
@arsenm: could you please review the AMDGPU changes? They were a bit fiddly, so you may prefer to tweak the prefixes in a different way, etc.

[asb]

lib/CodeGen/CodeGenPrepare.cpp

4207

This comment is now out-of-date, and needs updating.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp

985

Can you not check for a MemSDNode here, and avoid worrying about whether it's a LD or a ST?

test/CodeGen/RISCV/split-offsets-1.ll

4

Should probably check RV64 too

5

A comment should explain what this test is intending to check

test/CodeGen/RISCV/split-offsets-2.ll

2

This doesn't need to be in a separate file to the other test

[luismarques]

Addresses the remaining review concerns.

[asb]

Thanks, this looks good to me.

[craig.topper]

llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

1076 ↗

(On Diff #205016)

Doing some archaelogy.

Should this be checking the uses of the (add, (add, x, offset1), offset2)) expression? It seems to be checking the uses of (add x, offset1).

[luismarques]

llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

1076 ↗

(On Diff #205016)

It seems to be checking the uses of (add x, offset1).

Yes, you're right.

Should this be checking the uses of the (add, (add, x, offset1), offset2)) expression?

Yes, I think that would be the actually correct thing to do. It seems that, because the (add x, offset1) was also being used in the loads/stores, in practice this was working well enough for the test coverage we had (not sure about the real world). In fact, I think if you change it to check the uses of the proper value you won't see any changes at all for all CodeGen tests, for all targets. If you're planning to fix this, can you see if you can add a test case that shows the difference in behavior?

Thanks for spotting this issue, Craig! Sorry about the bug.

lib/CodeGen/CodeGenPrepare.cpp

if (VariableOperand == -1) {
         // Simple and common case that only one GEP is used in calculating the
         // address for the memory access.
         Value *Base = AddrInst->getOperand(0);
         auto *BaseI = dyn_cast<Instruction>(Base);
         auto *GEP = cast<GetElementPtrInst>(AddrInst);
         if (isa<Argument>(Base) || isa<GlobalValue>(Base) ||
             (BaseI && !isa<CastInst>(BaseI) &&
              !isa<GetElementPtrInst>(BaseI))) {
           // If the base is an instruction, make sure the GEP is not in the same
           // basic block as the base. If the base is an argument or global
           // value, make sure the GEP is not in the entry block.  Otherwise,
           // instruction selection can undo the split.  Also make sure the
           // parent block allows inserting non-PHI instructions before the
           // terminator.
           BasicBlock *Parent =
               BaseI ? BaseI->getParent() : &GEP->getFunction()->getEntryBlock();
-          if (GEP->getParent() != Parent && !Parent->getTerminator()->isEHPad())
+          if (!Parent->getTerminator()->isEHPad())
             LargeOffsetGEP = std::make_pair(GEP, ConstantOffset);
         }
       }
       AddrMode.BaseOffs -= ConstantOffset;
       return false;
     }
 
     // Save the valid addressing mode in case we can't match.
while (!worklist.empty()) {
     AddrModeInsts.clear();
     std::pair<AssertingVH<GetElementPtrInst>, int64_t> LargeOffsetGEP(nullptr,
                                                                       0);
     ExtAddrMode NewAddrMode = AddressingModeMatcher::Match(
         V, AccessTy, AddrSpace, MemoryInst, AddrModeInsts, *TLI, *TRI,
         InsertedInsts, PromotedInsts, TPT, LargeOffsetGEP);
 
     GetElementPtrInst *GEP = LargeOffsetGEP.first;
-    if (GEP && GEP->getParent() != MemoryInst->getParent() &&
-        !NewGEPBases.count(GEP)) {
+    if (GEP && !NewGEPBases.count(GEP)) {
       // If splitting the underlying data structure can reduce the offset of a
       // GEP, collect the GEP.  Skip the GEPs that are the new bases of
       // previously split data structures.
       LargeOffsetGEPMap[GEP->getPointerOperand()].push_back(LargeOffsetGEP);
       if (LargeOffsetGEPID.find(GEP) == LargeOffsetGEPID.end())
         LargeOffsetGEPID[GEP] = LargeOffsetGEPID.size();
     }
 

lib/CodeGen/SelectionDAG/DAGCombiner.cpp

private:
     SDValue visitFP16_TO_FP(SDNode *N);
     SDValue visitVECREDUCE(SDNode *N);
 
     SDValue visitFADDForFMACombine(SDNode *N);
     SDValue visitFSUBForFMACombine(SDNode *N);
     SDValue visitFMULForFMADistributiveCombine(SDNode *N);
 
     SDValue XformToShuffleWithZero(SDNode *N);
+    bool reassociationCanBreakAddressingModePattern(unsigned Opc,
+                                                    const SDLoc &DL, SDValue N0,
+                                                    SDValue N1,
+                                                    SDNodeFlags Flags);
     SDValue ReassociateOps(unsigned Opc, const SDLoc &DL, SDValue N0,
                            SDValue N1, SDNodeFlags Flags);
 
     SDValue visitShiftByConstant(SDNode *N, ConstantSDNode *Amt);
 
     SDValue foldSelectOfConstants(SDNode *N);
     SDValue foldVSelectOfConstants(SDNode *N);
     SDValue foldBinOpIntoSelect(SDNode *BO);

 // undef's.
 static bool isAnyConstantBuildVector(SDValue V, bool NoOpaques = false) {
   if (V.getOpcode() != ISD::BUILD_VECTOR)
     return false;
   return isConstantOrConstantVector(V, NoOpaques) ||
          ISD::isBuildVectorOfConstantFPSDNodes(V.getNode());
 }
 
+bool DAGCombiner::reassociationCanBreakAddressingModePattern(
+    unsigned Opc, const SDLoc &DL, SDValue N0, SDValue N1, SDNodeFlags Flags) {
+  if (Opc != ISD::ADD)
+    return false;
+
+  if (Flags.hasVectorReduction())
+    return false;
+
+  if (N0.getOpcode() != Opc || N0->getFlags().hasVectorReduction())
+    return false;
+
+  ConstantSDNode *C1 = dyn_cast<ConstantSDNode>(N0.getOperand(1));
+  ConstantSDNode *C2 = dyn_cast<ConstantSDNode>(N1);
+  if (!C1 || !C2)
+    return false;
+
+  const APInt &C1APIntVal = C1->getAPIntValue();
+  const APInt &C2APIntVal = C2->getAPIntValue();
+
+  if (C1APIntVal.getBitWidth() > 64 || C2APIntVal.getBitWidth() > 64)
+    return false;
+
+  TargetLoweringBase::AddrMode AM;
+  AM.HasBaseReg = true;
+  AM.BaseOffs = C2APIntVal.getSExtValue();
+
+  EVT VT = N0.getValueType();
+  Type *AccessTy = VT.getTypeForEVT(*DAG.getContext());
+
+  // If it already is not a legal addressing mode then we break nothing
+  if (!TLI.isLegalAddressingMode(DAG.getDataLayout(), AM, AccessTy, 0))
+    return false;
+
+  const APInt CombinedValue = C1APIntVal + C2APIntVal;
+  if (CombinedValue.getBitWidth() > 64)
+    return false;
+  AM.BaseOffs = CombinedValue.getSExtValue();
+  return !TLI.isLegalAddressingMode(DAG.getDataLayout(), AM, AccessTy, 0);
+}
+
 SDValue DAGCombiner::ReassociateOps(unsigned Opc, const SDLoc &DL, SDValue N0,
                                     SDValue N1, SDNodeFlags Flags) {
   // Don't reassociate reductions.
   if (Flags.hasVectorReduction())
     return SDValue();
 
   EVT VT = N0.getValueType();
   if (N0.getOpcode() == Opc && !N0->getFlags().hasVectorReduction()) {
if (N0.getOpcode() == ISD::OR &&
       return DAG.getNode(ISD::ADD, DL, VT, N0.getOperand(0), Add0);
     }
   }
 
   if (SDValue NewSel = foldBinOpIntoSelect(N))
     return NewSel;
 
   // reassociate add
+  if (!reassociationCanBreakAddressingModePattern(ISD::ADD, DL, N0, N1,
+                                                  N->getFlags())) {
     if (SDValue RADD = ReassociateOps(ISD::ADD, DL, N0, N1, N->getFlags()))
       return RADD;
+  }
 
   // fold ((0-A) + B) -> B-A
   if (N0.getOpcode() == ISD::SUB && isNullOrNullSplat(N0.getOperand(0)))
     return DAG.getNode(ISD::SUB, DL, VT, N1, N0.getOperand(1));
 
   // fold (A + (0-B)) -> A-B
   if (N1.getOpcode() == ISD::SUB && isNullOrNullSplat(N1.getOperand(0)))
     return DAG.getNode(ISD::SUB, DL, VT, N0, N1.getOperand(1));

lib/Target/RISCV/RISCVISelLowering.h

SDValue LowerReturn(SDValue Chain, CallingConv::ID CallConv, bool IsVarArg,
                       const SmallVectorImpl<SDValue> &OutVals, const SDLoc &DL,
                       SelectionDAG &DAG) const override;
   SDValue LowerCall(TargetLowering::CallLoweringInfo &CLI,
                     SmallVectorImpl<SDValue> &InVals) const override;
   bool shouldConvertConstantLoadToIntImm(const APInt &Imm,
                                          Type *Ty) const override {
     return true;
   }
+  bool shouldConsiderGEPOffsetSplit() const override { return true; }
   SDValue lowerGlobalAddress(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerBlockAddress(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerConstantPool(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerSELECT(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerVASTART(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerFRAMEADDR(SDValue Op, SelectionDAG &DAG) const;
   SDValue lowerRETURNADDR(SDValue Op, SelectionDAG &DAG) const;
 

test/CodeGen/RISCV/split-offsets-1.ll

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32I
+
+define void @test1([65536 x i32]** %sp, [65536 x i32]* %t, i32 %n) {
+; RV32I-LABEL: test1:
+; RV32I:       # %bb.0: # %entry
+; RV32I-NEXT:    lui a2, 20
+; RV32I-NEXT:    addi a2, a2, -1920
+; RV32I-NEXT:    lw a0, 0(a0)
+; RV32I-NEXT:    add a0, a0, a2
+; RV32I-NEXT:    addi a3, zero, 1
+; RV32I-NEXT:    sw a3, 4(a0)
+; RV32I-NEXT:    addi a4, zero, 2
+; RV32I-NEXT:    sw a4, 0(a0)
+; RV32I-NEXT:    add a0, a1, a2
+; RV32I-NEXT:    sw a4, 4(a0)
+; RV32I-NEXT:    sw a3, 0(a0)
+; RV32I-NEXT:    ret
+entry:
+  %s = load [65536 x i32]*, [65536 x i32]** %sp
+  %gep0 = getelementptr [65536 x i32], [65536 x i32]* %s, i64 0, i32 20000
+  %gep1 = getelementptr [65536 x i32], [65536 x i32]* %s, i64 0, i32 20001
+  %gep2 = getelementptr [65536 x i32], [65536 x i32]* %t, i64 0, i32 20000
+  %gep3 = getelementptr [65536 x i32], [65536 x i32]* %t, i64 0, i32 20001
+  store i32 2, i32* %gep0
+  store i32 1, i32* %gep1
+  store i32 1, i32* %gep2
+  store i32 2, i32* %gep3
+  ret void
+}

test/CodeGen/RISCV/split-offsets-2.ll

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32I
+
+define void @test2([65536 x i32]** %sp, [65536 x i32]* %t, i32 %n) {
+; RV32I-LABEL: test2:
+; RV32I:       # %bb.0: # %entry
+; RV32I-NEXT:    lui a3, 20
+; RV32I-NEXT:    addi a3, a3, -1920
+; RV32I-NEXT:    lw a0, 0(a0)
+; RV32I-NEXT:    add a0, a0, a3
+; RV32I-NEXT:    add a1, a1, a3
+; RV32I-NEXT:    mv a3, zero
+; RV32I-NEXT:    bge a3, a2, .LBB0_2
+; RV32I-NEXT:  .LBB0_1: # %while_body
+; RV32I-NEXT:    # =>This Inner Loop Header: Depth=1
+; RV32I-NEXT:    sw a3, 4(a0)
+; RV32I-NEXT:    addi a4, a3, 1
+; RV32I-NEXT:    sw a4, 0(a0)
+; RV32I-NEXT:    sw a3, 4(a1)
+; RV32I-NEXT:    sw a4, 0(a1)
+; RV32I-NEXT:    mv a3, a4
+; RV32I-NEXT:    blt a3, a2, .LBB0_1
+; RV32I-NEXT:  .LBB0_2: # %while_end
+; RV32I-NEXT:    ret
+entry:
+  %s = load [65536 x i32]*, [65536 x i32]** %sp
+  br label %while_cond
+while_cond:
+  %phi = phi i32 [ 0, %entry ], [ %i, %while_body ]
+  %gep0 = getelementptr [65536 x i32], [65536 x i32]* %s, i64 0, i32 20000
+  %gep1 = getelementptr [65536 x i32], [65536 x i32]* %s, i64 0, i32 20001
+  %gep2 = getelementptr [65536 x i32], [65536 x i32]* %t, i64 0, i32 20000
+  %gep3 = getelementptr [65536 x i32], [65536 x i32]* %t, i64 0, i32 20001
+  %cmp = icmp slt i32 %phi, %n
+  br i1 %cmp, label %while_body, label %while_end
+while_body:
+  %i = add i32 %phi, 1
+  %j = add i32 %phi, 2
+  store i32 %i, i32* %gep0
+  store i32 %phi, i32* %gep1
+  store i32 %i, i32* %gep2
+  store i32 %phi, i32* %gep3
+  br label %while_cond
+while_end:
+  ret void
+}