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

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

Hi Paul,

On 02/26/2013 06:13 AM, Redmond, Paul wrote:
> 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
Isn't it possible that multiple nested loops share the header and
the pre-header in normalized loops? Thus, then adding metadata to the
preheader's branch would make the MD ambiguous for nested loops.

-- 
--Pekka

Hi Pekka,

On Tue, Feb 26, 2013 at 11:08 AM, Pekka Jääskeläinen <
pekka.jaaskelainen at tut.fi> wrote:
>
>
> Isn't it possible that multiple nested loops share the header and
> the pre-header in normalized loops? Thus, then adding metadata to the
> preheader's branch would make the MD ambiguous for nested loops.
>
> The header can't be shared, otherwise it's the same loop. Though
strictly
speaking it depends on definition of the loop, but in my experience, the
most practical definition is "loop == header".

Another observation is that pre-header is highly important for
optimizations as a placeholder for hoisting the code out of the loop. So
even if the pre-header doesn't exist, it makes sense to create it during
optimization. But pre-header of the inner loop may make it more difficult
to detect that loop-nest is perfect nest (i.e. the only real code of
the outer loop is the inner loop).

-Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130226/ee32bb10/attachment.html>