llvm dev - Feb 2013 - [LLVMdev] loop metdata instruction

Hi,

On 2013-02-25 8:22 PM, "Krzysztof Parzyszek" <kparzysz at
codeaurora.org>
wrote:
>On 2/25/2013 4:50 PM, Redmond, Paul wrote:
>>
>> On the branch into the loop:
>
>Well... In this case the metadata is not on the latch.  I guess this is
>because the initial loop structure is this questionable
>jump-to-cond-then-back scheme.  I agree---this doesn't look right.
This loop structure is not questionable--it's what clang generates for a
for loop..

I'm suggesting this as a possible alternative to the loop latch approach.
Please re-read my original email.

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

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.

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.


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

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