Re: decrement_and_branch_until_zero pattern

[Paul Koning <paulkoning at comcast dot net>]

> On Jun 8, 2018, at 6:16 PM, Jim Wilson <jimw@sifive.com> wrote:
> 
> On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning <paulkoning@comcast.net> wrote:
>> Thanks.  I saw those sections and interpreted them as support for signal processor style fast hardware loops.  If they can be adapted for dbra type looping, great.  I'll give that a try.
> 
> The rs6000 port uses it for bdnz (branch decrement not zero) for
> instance, which is similar to the m68k dbra.
> 
>> Meanwhile, yes, it looks like there is a documentation bug.  I can clean that up.  It's more than a few lines, but does that qualify for an "obvious" change?
> 
> I think the obvious rule should only apply to trivial patches, and
> this will require some non-trivial changes to fix the looping pattern
> section.  Just deleting the decrement_and_branch_until_zero named
> pattern section looks trivial.  It looks like the REG_NONNEG section
> should  mention the doloop_end pattern instead of
> decrement_and_branch_until_zero, since I think the same rule applies
> that they only get generated if the doloop_end pattern exists.

It appears that doloop_end doesn't get a REG_NONNEG pattern.  I just added doloop_end to my target and I don't see any such note in the RTL dumps.

By the way, the documentation makes it clear that the register used in the doloop isn't available as an "induction variable".  I wonder if there is a way to make that restriction go away, since my target -- and I suspect several others as well -- use a general register for the loop control.  So as far as the target is concerned the loop control register is definitely available.  I understand the original restriction for machines like DSPs that loop using special-purpose loop registers, but that isn't a universal limitation.

	paul