[LLVMdev] Question about shouldMergeGEPs in InstructionCombining

Hal Finkel hfinkel at anl.gov
Mon Feb 23 11:17:22 PST 2015


----- Original Message -----
> From: "Francois Pichet" <pichet2000 at gmail.com>
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Sunday, February 22, 2015 5:34:11 PM
> Subject: [LLVMdev] Question about shouldMergeGEPs in InstructionCombining
>
> Hello
> 
> I am not sure I understand the logic for merging GEPs in
> InstructionCombining.cpp:
> 
> static bool shouldMergeGEPs (GEPOperator &GEP, GEPOperator &Src) {
> // If this GEP has only 0 indices, it is the same pointer as
> // Src. If Src is not a trivial GEP too, don't combine
> // the indices.
> if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&
> !Src.hasOneUse())
> return false;
> return true;
> }
> 
> 
> 
> I have a case where
> GEP: %arrayidx7 = getelementptr inbounds i32* %arrayidx, i32 %shl6
> Src: %arrayidx = getelementptr inbounds [4096 x i32]* @phasor_4096,
> i32 0, i32 %shl2
> 
> 
> GEP. hasAllZeroIndices() will return false and the merge will occur
> Why do we want to combine these 2 getelementptr?
> 
> 
> On my out of tree target, combining these 2 GetElementPtr create a
> performance regression because since GEP is in a loop (Src is out of
> loop), GEP will lower to a more complicated address for a subsequent
> load. (the complicated address needs to be calculated over and over
> in the loop)
> 

There are a couple of issues here. One, InstCombine's job is the move the IR toward a reasonable canonical form. It is doing that here, and I think that's the right thing to do. However, the problem you point out is a general one. Can you please explain why the MachineLICM pass is not able to hoist the redundant parts of the addressing computation out of the loop? We might also want to adjust for this in CodeGenPrep (CGP already has addressing-mode aware GEP splitting logic, although not quite for this case).

 -Hal

> 
> Thanks.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list