> On Jun 8, 2018, at 6:16 PM, Jim Wilson <j...@sifive.com> wrote:
>
> On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning <paulkon...@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
