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

[Hal Finkel]

----- Original Message -----
> ----- Original Message -----
> > From: "Brendon Cahoon" <bcahoon at codeaurora.org>
> > To: "Hal Finkel" <hfinkel at anl.gov>, "Krzysztof Parzyszek"
> > <kparzysz at codeaurora.org>
> > Cc: llvm-commits at cs.uiuc.edu
> > Sent: Wednesday, May 1, 2013 1:41:01 PM
> > Subject: RE: [llvm] r174904 - Extend Hexagon hardware loop
> > generation to	handle various additional cases:
> > 
> > Hi Hal,
> > 
> > We recently had a bug opened internally on a very similar loop.
> >  For
> > us, the
> > problem occurs when we set the hardware loop counter to 0, and the
> > loop
> > decrements the value in the first iteration.  If it's an unsigned
> > value,
> > then the loop should execute MAX_INT iterations, but our hardware
> > loop
> > instruction only executes the loop once.  If it's signed, I don't
> > think it
> > matters since the behavior is undefined.
> > 
> > I think you're on the right track about getting help from an IR
> > level
> > pass.
> > I think it may be enough to have the signed/unsigned wrap flag
> > propagated to
> > the MI level for the induction variable decrement.  If the nuw/nsw
> > flag is
> > not there, then don't generate a hardware loop.  I'm not sure it's
> > that a
> > desirable solution though.
> 
> It took some time, but I now have this working as an IR level pass
> (plus some intrinsics and plus a cleanup pass to set live-in flags
> and
> remove some dead use flags). I have some code cleanup to do, and I
> plan on committing this, probably tomorrow (after 3.3 branches).

Here it is: r181927. Please let me know what you think.

 -Hal

> 
>  -Hal
> 
> > 
> > Thanks,
> > Brendon
> > 
> > -----Original Message-----
> > From: llvm-commits-bounces at cs.uiuc.edu
> > [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
> > ----- Original Message -----
> > > From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> > > 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
> > 
> > 
> > 
>