Re: RFD: doloop needs better support for nested loops

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Oct 10, 2023 at 2:43 PM Joern Rennecke
<joern.rennecke@embecosm.com> wrote:
>
> I'm working on implementing hardware loops for the CORE-V CV32E40P
> https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/corev_hw_loop.html
>
> This core supports nested hardware lops, but does not allow any other flow
> control inside hardware loops.  I found that our existing interfaces do not
> allow sufficient control over when to emit doloop patterns, i.e. allowing
> nested doloops while rejecting other flow control inside the loop.
>
> TARGET_CAN_USE_DOLOOP_P does not get passed anything to look at the
> individual loop.  Most convenient would be the loop structure, although
> that would cause tight coupling of the target port with the internal data
> structures of the loop optimizers.

I don't think this would really be an issue, the loop structure is really
part of the CFG structure nowadays.

> OTOH we already have a precedent with TARGET_PREDICT_DOLOOP_P .
>
> TARGET_INVALID_WITHIN_DOLOOP is missing context.  We neither know the loop
> nesting depth, nor if any jump instruction under consideration is the final
> branch to jump back to the loop latch.  Actually, the seccond part is the
> main problem for the CV32E40P: inner doloops that have been transformed
> can be recognized as such, but un-transformed condjumps could either be
> spaghetti code inside the loop or the final jump instruction of the loop.
>
> The doloop_end pattern is also missing context to make meaningful decisions.
> Although we know the label where the pattern is supposed to jump to,
> we don't know where the original branch is.  Even if we scan the insn
> stream, this is ambigous, since there can be two (or more) nested doloop
> candidates.
> What we could do here is add optional arguments; there is precedence, e.g.
> for the call pattern.  The advantage of this approach is that ports that
> are fine with the current interface need not be patched.
> To make it possible to scritinze the control flow of the loop, the branch
> at the end of the loop makes a good optional argument.
>
> There is also the issue that loop setup is a bit more costly for large loops,
> and it would be nice to weigh that against the iteration count.  We had
> information about the iteration count at TARGET_CAN_USE_DOLOOP_P, but
> nothing to allow us to analyze the loop body.  Although the port could
> stash avay the iteration count into a globalvariable or machine_function
> member, it would be more straightforward and robust to pass the information
> together so that it can be considered in context.
>
> Attached is an patch for an optional 3rd parameter to doloop_end .