llvm dev - May 2019 - Making loop guards part of canonical loop structure

I don't remember the details of the particular case where we encountered
this, but I think the loop started with the condition check and ended with an
unconditional branch back to the beginning.

-- 
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: Philip Reames <listmail at philipreames.com> 
Sent: Thursday, May 30, 2019 3:00 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; Finkel, Hal J.
<hfinkel at anl.gov>; Kit Barton <kit.barton at gmail.com>; llvm-dev
at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Making loop guards part of canonical loop
structure

Er, I'm missing something.  Every loop header is guaranteed to execute at
least once, if the preheader is reached.  How is what you need anything more
than a loop header with a unique predecessor (preheader)? I'm not seeing the
need for a guard block in what you said.

Philip

On 5/30/19 11:28 AM, Krzysztof Parzyszek via llvm-dev
wrote:
> On Hexagon, unguarded loops cannot be converted to hardware loops.
>
> If the loop's latch branch alone handles the iteration count, including
the possibility of 0, then the loop cannot be converted to a hardware loop,
because hardware loops must iterate at least once.  If the entire loop is
guarded against zero iteration count, we can put the loop setup in the
preheader, since at that point the loop is guaranteed to execute at least once.
>
> I am strongly in favor of having some way to create loop guards, even if
they are trivial.
>

Seems like a case which should be handled by loop rotation.  If you find
a reproducer for it, that's where I'd start looking rather than anything
specific to guarded loops. 

Philip

On 5/30/19 1:44 PM, Krzysztof Parzyszek wrote:
> I don't remember the details of the particular case where we
encountered this, but I think the loop started with the condition check and
ended with an unconditional branch back to the beginning.
>

That sounds like it wasn't being rotated then?

I don't know that what I'm proposing would help you in that case -
although I would be very happy if it did :)

If you can dig up some details and send it to me, I'd like to see we can
find a way to make it work. One of the things I don't have a good
feeling for right now is how many loops (in general) we are able to
successfully rotate and/or simplify. This will have an impact on the
overall effectiveness of loop optimizations in general, as we move
forward.


Krzysztof Parzyszek <kparzysz at quicinc.com> writes:
> I don't remember the details of the particular case where we
encountered this, but I think the loop started with the condition check and
ended with an unconditional branch back to the beginning.

I don't really care that much about that particular case.  We generate
hardware loops somewhat late in codegen, so this is long past IR-level loop
transformations.  It's just a case where having guarded loops would make
things easier to analyze, regardless of how the loop code may have been
reorganized in the meantime.

-- 
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: Philip Reames <listmail at philipreames.com> 
Sent: Thursday, May 30, 2019 4:57 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; Finkel, Hal J.
<hfinkel at anl.gov>; Kit Barton <kit.barton at gmail.com>; llvm-dev
at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Making loop guards part of canonical loop
structure

Seems like a case which should be handled by loop rotation.  If you find a
reproducer for it, that's where I'd start looking rather than anything
specific to guarded loops. 

Philip

On 5/30/19 1:44 PM, Krzysztof Parzyszek wrote:
> I don't remember the details of the particular case where we
encountered this, but I think the loop started with the condition check and
ended with an unconditional branch back to the beginning.
>

Outlook removed llvm-dev from the recipient list, so re-replying.

-- 
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: Krzysztof Parzyszek <kparzysz at quicinc.com> 
Sent: Friday, May 31, 2019 10:41 AM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; Philip Reames
<listmail at philipreames.com>; Finkel, Hal J. <hfinkel at anl.gov>;
Kit Barton <kit.barton at gmail.com>
Subject: RE: [EXT] Re: [llvm-dev] Making loop guards part of canonical loop
structure

Actually, having guards inserted in codegen would require loop analysis to be
able to compute iteration counts of MI loops (which we don't really do
generically right now).  So, this isn't really an applicable argument at the
moment.

Still, on the IR level, having a consistent loop structure could simplify code
that analyzes loops (as in Kit's example).

-- 
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof
Parzyszek via llvm-dev
Sent: Friday, May 31, 2019 10:32 AM
To: Philip Reames <listmail at philipreames.com>; Finkel, Hal J.
<hfinkel at anl.gov>; Kit Barton <kit.barton at gmail.com>; llvm-dev
at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Making loop guards part of canonical loop
structure

I don't really care that much about that particular case.  We generate
hardware loops somewhat late in codegen, so this is long past IR-level loop
transformations.  It's just a case where having guarded loops would make
things easier to analyze, regardless of how the loop code may have been
reorganized in the meantime.

-- 
Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development

-----Original Message-----
From: Philip Reames <listmail at philipreames.com> 
Sent: Thursday, May 30, 2019 4:57 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; Finkel, Hal J.
<hfinkel at anl.gov>; Kit Barton <kit.barton at gmail.com>; llvm-dev
at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Making loop guards part of canonical loop
structure

Seems like a case which should be handled by loop rotation.  If you find a
reproducer for it, that's where I'd start looking rather than anything
specific to guarded loops. 

Philip

On 5/30/19 1:44 PM, Krzysztof Parzyszek wrote:
> I don't remember the details of the particular case where we
encountered this, but I think the loop started with the condition check and
ended with an unconditional branch back to the beginning.
>
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev