On 06/04/2018 09:02 AM, Paul Koning wrote: > > >> On Jun 4, 2018, at 10:09 AM, Jeff Law <l...@redhat.com> wrote: >> >> On 06/04/2018 08:06 AM, Paul Koning wrote: >>> >>> >>>> On Jun 4, 2018, at 9:51 AM, Jeff Law <l...@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? Yes and no :-) I suspect no real thought was given to what happens when there's more than one auto-inc in the pattern, regardless of what happens in the final instruction.
I realize that in your case the operand appears twice in the RTL, but just once in the final output. One might argue that if the operands in the pattern are tied together via a match_dup that we ought to be able to support it. But I doubt anyone has thought much about it. Jeff
