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

[Hal Finkel]

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Wednesday, May 1, 2013 10:47:39 AM
> Subject: Re: [llvm] r174904 - Extend Hexagon hardware loop generation to handle various additional cases:
> 
> On 5/1/2013 8:16 AM, Hal Finkel wrote:
> >
> > 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).
> 
> I didn't have time to look into this problem yet, but given this
> explanation I agree that there is a problem with unguarded loops.
>  I'm
> not sure what to do with it either.  We actually have thought that
> MI-level SCEV would be nice, but that's where it ended.
> 
> What I'm thinking about at the moment is some sort of loop
> transformation that would prepare loops for converting into HW form,
> but
> I have nothing concrete yet.
> 
> Thanks for pointing this out.  This definitely needs to be addressed.

Alright, I'll work on this today. If I come up with something worthwhile, then you can be the copier this time ;)

 -Hal

> 
> -Krzysztof
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>