[llvm] r174904 - Extend Hexagon hardware loop generation to handle various additional cases:

[Hal Finkel]

----- Original Message -----
> From: "Hal Finkel" <hfinkel at anl.gov>
> To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Sunday, April 28, 2013 9:35:15 AM
> Subject: Re: [llvm] r174904 - Extend Hexagon hardware loop generation to	handle various additional cases:
> 
> Krzysztof,
> 
> Does this new pass correctly handle
> test-suite/SingleSource/UnitTests/2008-04-20-LoopBug2.c on Hexagon?
> My PowerPC port does not because, unlike in 2008-04-18-LoopBug.c for
> example, the loop (canonicalization) passes don't generate a guard
> condition that dominates the loop. As a result, when the iteration
> count is computed (imm - reg), where (reg > imm), the count is
> negative and this negative count is loaded into the counter
> register. On PowerPC, because the count register branch condition is
> based on equality with zero, the loop is not skipped as it should
> be. Maybe the semantics of the Hexagon looping instructions protect
> it from this problem. If so, you should probably note that
> somewhere.

I realized my comment could be a little unclear. There is no loop guard for 2008-04-20-LoopBug2.c because there shouldn't be. It is a do-while loop, and so the first iteration is always executed. The problem is that the lack of the guard means nothing prevents us from generating negative count values.

I can't think of any great solutions to this problem. We can check the predecessors for simple guards, but they might be difficult to find if they've been hoisted out of loops and/or combined with other conditions. Alternatively, maybe the counts should be generated by some IR-level pass (maybe using SCEV, and put into some intrinsic, selected to a pseudo instruction, that can either be converted by the hardware loops pass, or DCE'd).

Thanks again,
Hal

> 
> Thanks again,
> Hal
> 
> ----- Original Message -----
> > From: "Hal Finkel" <hfinkel at anl.gov>
> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> > Cc: llvm-commits at cs.uiuc.edu
> > Sent: Saturday, April 27, 2013 12:13:16 PM
> > Subject: Re: [llvm] r174904 - Extend Hexagon hardware loop
> > generation to	handle various additional cases:
> > 
> > ----- Original Message -----
> > > From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> > > To: "Hal Finkel" <hfinkel at anl.gov>
> > > Cc: llvm-commits at cs.uiuc.edu
> > > Sent: Saturday, April 27, 2013 12:05:43 PM
> > > Subject: Re: [llvm] r174904 - Extend Hexagon hardware loop
> > > generation to handle various additional cases:
> > > 
> > > On 4/26/2013 10:53 PM, Hal Finkel wrote:
> > > >
> > > > I'd found from working with the first version of this pass,
> > > > ported
> > > > to PPC, that I needed to add the counter register as live-in to
> > > > all non-preheader loop blocks (or at least to LastMBB). Do you
> > > > need to do something similar here? [for machine-code
> > > > verification.]
> > > 
> > > Hi Hal,
> > > 
> > > Thanks for the additional comments---I just read them and I
> > > haven't
> > > thought about them in detail yet, but just to comment on the
> > > liveness
> > > remark above: the registers (SAn and LCn, n=0,1) that control
> > > hardware
> > > loop execution on Hexagon are marked as reserved, which (IIRC)
> > > exempts
> > > them from the liveness tracking.
> > 
> > Okay, that makes sense. I may have to do this on PPC as an artifact
> > of how the counter register is setup (it has a single-register
> > register class, although that's not used here).
> > 
> > > 
> > > On the other comments---you're most likely right.  The code has
> > > evolved
> > > from a simpler version, and some pieces of it that were needed
> > > earlier
> > > may no longer be necessary.  In the long run it should be
> > > refactored
> > > to
> > > common out the functionality that could be shared between
> > > architectures.
> > 
> > I agree; but I think the first step is to synchronize
> > functionality.
> > 
> > >   Unfortunately, the way the code is currently written is
> > > Hexagon-centric, and so each time you have to go through the
> > > porting
> > > process.
> > 
> > Hopefully this will be a converging process ;)
> > 
> > Thanks again,
> > Hal
> > 
> > > 
> > > -Krzysztof
> > > 
> > > --
> > > Qualcomm Innovation Center, Inc. is a member of Code Aurora
> > > Forum,
> > > hosted by The Linux Foundation
> > > 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>