[LLVMdev] loop metdata instruction

[Redmond, Paul]

Hi,

On 2013-02-25 10:20 PM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
wrote:

>On 2/25/2013 7:41 PM, Redmond, Paul wrote:
>>
>> I'm suggesting this as a possible alternative to the loop latch
>>approach.
>> Please re-read my original email.
>
>Your reply seemed like you're quoting code that is currently generated,
>not your proposal.

Oops, sorry for not being clear. The code I presented is what I was
experimenting with.

>
>I'm not sure why you would want the loop metadata to be attached to some
>other branch.  Loop latch will always exist, while, at least at this
>time, there is no guarantee that the "other" branch (the loop guard)
>will exist.  Besides, there is a member function in the Loop class that
>gives you the latch block, from which you can easily get to the
>terminator and then the metadata.

Is this not true for the loop pre-header as well? (Putting the metadata on
the branch in the loop pre-header is basically what I proposed)

I don't know if one way is better than the other to be honest--which is
why I'm asking. One case where having the metadata outside the loop is
more convenient is loop unrolling. With the metadata inside the loop you
have to update multiple branches whereas metadata outside the loop you
should not have to do anything. It's possible there are cases where
metadata inside the loop is more convenient.

The point is if the two representations are equivalent (which is what I'd
like to determine) and one is more convenient/less intrusive on existing
passes than that should be determined sooner rather than later :P

paul

>
>
>As for the questionable part---I know that this is what clang generates,
>and there is probably little chance of changing it in near future, but
>this loop structure is just bad for optimization.  The loop, as it is
>generated, has an early exit and an unconditional latch.  What comes out
>of loop rotation in your example is what ideally it would be from the
>beginning.  Apart from all that, SimplifyCFG would have it a lot easier
>not to damage loops that at point may not even appear to be loops.
>
>-Krzysztof
>
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation