[llvm-dev] Some questions about software pipeline in LLVM 4.0.0

Brendon Cahoon via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 26 15:22:34 PDT 2017


Hi Ehsan,

 

In some cases modulo scheduling will insert copy instruction that end up as
real copies in the final code.  It unavoidable in some cases.  For example,
let's say a instruction defining a value is scheduled in the first
iteration, but one of its uses is scheduled two iterations later. In this
case, the kernel needs to create a copy because there will be two values
live in the kernel, from two other iterations.

 

        = R1     // use of the value from iteration n-2

        = R0     // use of the value from iteration n-1

  R0 = insn  // def at iteration n

  R1 = R0  

 

If all the uses of an instruction occur at most one iteration away, and the
uses appear before the definition, then the copies should be coalesced away.

 

In the examples that you show below, it all depends in which iteration each
instruction is scheduled and/or the order in which the instructions are
scheduled.

  %vreg73<def> = PHI %vreg59, <BB#5>, %vreg62, <BB#6>;

  %vreg61<def> = INSN1 %vreg1, %vreg73;

  %vreg62<def> = INSN2 %vreg73, %vreg5;

  %vreg64<def> = INSN1 %vreg2, %vreg73;

 

For some reason, the instruction defining vreg64 was scheduled after the
instruction defining vreg62, which causes the copy to be generated.  Then,
the question is why did that happen? That can be hard to answer without
seeing the debug output from the pipeliner. In what order were the
instructions scheduled? I would assume that its either vreg73, vreg61,
vreg64, and then vreg62 , or it's the opposite order.  If that's the case,
then there was a cycle gap in between the scheduling of vreg61 and vreg64,
so vreg62 was inserted in between them. Perhaps, there are multi-cycle
latencies that left the hole?  Also, can multiple instructions be executed
in parallel in the same cycle?

 

Let me know if any of that isn't clear.  I apologize for the delay in
replying to your original email.

 

Thanks,

Brendon

 

From: Ehsan Amiri [mailto:ehsan.amiri at huawei.com] 
Sent: Monday, June 19, 2017 1:55 AM
To: Brendon Cahoon <bcahoon at codeaurora.org>
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] Some questions about software pipeline in LLVM 4.0.0

 

Hi Brendon

 

Certainly, there are some real copies that end up being generated, but I
think it's better to exclude the copies from the schedule since most will be
eliminated. 

 

I was wondering what was the cause of the real copies that was being
generated in your experience? Something that I noticed when experimenting
with LLVM on our out-of-tree backend, was that there are copy instructions
generated **because of** modulo scheduling. 

 

For example before modulo scheduling I have 

 

%vreg6<def> = PHI %vreg23, <BB#1>, %vreg17

%vreg25<def> = INSN1 %vreg1, %vreg6;

% vreg26<def> = INSN1 %vreg2, %vreg6     <-- same opcode as previous insn

% vreg17<def> = INSN2 %vreg6, %vreg5;

 

So for the phi node here, if we do phi elimination and register coalescing,
we won't have any copy insn left. But after modulo scheduling the
instructions above, now appear like this:

 

%vreg73<def> = PHI %vreg59, <BB#5>, %vreg62, <BB#6>;

%vreg61<def> = INSN1 %vreg1, %vreg73;

%vreg62<def> = INSN2 %vreg73, %vreg5;

%vreg64<def> = INSN1 %vreg2, %vreg73;

 

Now if you look right after the third insn after modulo scheduling, both
vreg73 and vreg62 are live here. So when we remove the corresponding phi
instruction, we end up with a copy instruction that cannot be removed by
register coalescing. 

 

IIUC, this is a byproduct of modulo scheduling. I have not really started
tuning modulo scheduling for our target, so I don't know if this is a result
of modulo scheduling not being tuned or not? Have you seen this type of
Copy? Any insights are greatly appreciated.

 

Thanks

Ehsan

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170626/8561c956/attachment.html>


More information about the llvm-dev mailing list