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.
Jeff
