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

[Brendon Cahoon]

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.

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