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

[Krzysztof Parzyszek]

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.

-Krzysztof

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