in/out operands and auto-inc-dec

[Paul Koning]

> On Jun 4, 2018, at 10:09 AM, Jeff Law <law@redhat.com> wrote:
> 
> On 06/04/2018 08:06 AM, Paul Koning wrote:
>> 
>> 
>>> On Jun 4, 2018, at 9:51 AM, Jeff Law <law@redhat.com> wrote:
>>> 
>>> On 06/04/2018 07:31 AM, Paul Koning wrote:
>>>> The internals manual in its description of the "matching constraint" says that it works for cases where the in and out operands are somewhat different, such as *p++ vs. *p.  Obviously that is meant to cover post_inc side effects.
>>>> 
>>>> The curious thing is that auto-inc-dec.c specifically avoids doing this: if it finds what looks like a suitable candidate for auto-inc or auto-dec optimization but that operand occurs more than once in the insn, it doesn't make the change.  The result is code that's both larger and slower for machines that have post_inc etc. addressing modes.  The gccint documentation suggests that it was the intent to optimize this case, so I wonder why it is avoided.
>>> I wouldn't be terribly surprised if the old flow.c based auto-inc
>>> discovery handled this, but the newer auto-inc-dec.c doesn't.  The docs
>>> were probably written prior to the conversion.
>> 
>> That fits, because there is a reference to "the flow pass of the compiler" when these constructs are introduced in section 14.16.
>> 
>> So is this an omission, or is there a reason why that optimization was removed?  
> I would guess omission, probably on the assumption it wasn't terribly
> important and there wasn't really a good way to test it.    There aren't
> many targets that use auto-inc getting a lot of attention these days,
> and those that do can't have multiple memory operands.

By "multiple memory operands" do you mean both source and dest in memory?  Ok, but I didn't mean that specifically.  The issue is on an instruction with a read/modify/write destination operand, like two-operand add.  If the destination looks like a candidate for post-inc, it's skipped because it shows up twice in the RTL -- since that uses three operand notation.

For example:

    for (int i = 0; i < n; i++)
        *p++ += i;

produces (on pdp11):
	add $02, r0
	add r1, -02(r0)

rather than simply "add r1, (r0)+".  But if I change the += to =, the expected optimization does take place.

	paul