On Wed, 2020-08-26 at 12:19 +0100, Roger Sayle wrote: > Hi Dave, > > > This change is also fine. > > > > The gcc.target/hppa/shadd-2.c test now fails because there are two > additional sh1add instructions. > > However, the total number of instructions is the same as before. > > Just to be on the safe side, I took a deeper look into this. > We're now generating a slightly different sequence for multiply by 87. > > Before: > zdep %r28,28,29,%r20 ; r20 = r28*8 > ldo RR'default_target_regs-$global$(%r1),%r19 > sub %r20,%r28,%r20 ; r20 = r28*7 > sh2addl %r20,%r28,%r20 ; r20 = r28*29 > sh2addl %r20,%r19,%r19 ; r20 = addr+r28*116 > sub %r19,%r20,%r19 ; r20 = addr+r28*87 > > After: > sh2addl %r28,%r28,%r19 ; r19 = r28*5 > ldo RR'default_target_regs-$global$(%r1),%r1 > sh2addl %r19,%r28,%r19 ; r19 = r28*21 > sh1addl %r19,%r28,%r19 ; r19 = r28*43 > sh1addl %r19,%r28,%r19 ; r19 = r28*87 > addl %r1,%r19,%r1 ; r1 = addr+r28*87 > > As you point out, both sequences have exactly the same length and rtx_costs. > I suspect the middle-end has a minor preference for simple shifts and adds. > If shadd-2.c is there to check we make use of sh?add instructions, then > we're > making even more use of them now. > > I agree it's reasonable to increase the scan-assembler-times count for this > test. Yes, those tests were there to catch failure to create shadd insns after some changes in the combiner. If we're generating more, then that's good enough for those tests :-)
jeff
