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

[Hal Finkel]

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.

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
>