This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation


On 17/11/16 14:55, Kyrill Tkachov wrote:


On 17/11/16 14:44, Segher Boessenkool wrote:

Hi Kyrill,

On Thu, Nov 17, 2016 at 02:22:08PM +0000, Kyrill Tkachov wrote:

I ran SPEC2006 on a Cortex-A72. Overall scores were neutral but there
were
some interesting swings.
458.sjeng     +1.45%
471.omnetpp   +2.19%
445.gobmk     -2.01%

On SPECFP:
453.povray    +7.00%

After looking at the gobmk performance with performance counters it looks
like more icache pressure.
I see an increase in misses.
This looks to me like an effect of code size increase, though it is not
that large an increase (0.4% with SWS).

Right.  I don't see how to improve on this (but see below); ideas welcome :-)


Branch mispredicts also go up a bit but not as much as icache misses.

I don't see that happening -- for some testcases we get unlucky and have
more branch predictor aliasing, and for some we have less, it's pretty
random.  Some testcases are really sensitive to this.


Right, I don't think it's the branch prediction at fault in this case,
rather the above icache stuff.




I don't think there's anything we can do here, or at least that this patch
can do about it.
Overall, there's a slight improvement in SPECINT, even with the gobmk
regression and a slightly larger improvement
on SPECFP due to povray.

And that is for only the "normal" GPRs, not LR or FP yet, right?


This patch does implement FP registers wrapping as well but not LR.
Though I remember seeing the improvement even when only GPRs were wrapped
in an earlier version of the patch.


Segher, one curious artifact I spotted while looking at codegen differences
in gobmk was a case where we fail
to emit load-pairs as effectively in the epilogue and its preceeding basic
block.
So before we had this epilogue:
.L43:
     ldp    x21, x22, [sp, 16]
     ldp    x23, x24, [sp, 32]
     ldp    x25, x26, [sp, 48]
     ldp    x27, x28, [sp, 64]
     ldr    x30, [sp, 80]
     ldp    x19, x20, [sp], 112
     ret

and I see this becoming (among numerous other changes in the function):

.L69:
     ldp    x21, x22, [sp, 16]
     ldr    x24, [sp, 40]
.L43:
     ldp    x25, x26, [sp, 48]
     ldp    x27, x28, [sp, 64]
     ldr    x23, [sp, 32]
     ldr    x30, [sp, 80]
     ldp    x19, x20, [sp], 112
     ret

So this is better in the cases where we jump straight into .L43 because we
load fewer registers
but worse when we jump to or fallthrough to .L69 because x23 and x24 are
now restored using two loads
rather than a single load-pair. This hunk isn't critical to performance in
gobmk though.

Is loading/storing a pair as cheap as loading/storing a single register?
In that case you could shrink-wrap per pair of registers instead.


I suppose it can vary by microarchitecture. For the purposes of codegen I'd say
it's more expensive than load/storing a single register (as there's more memory bandwidth required after all)
but cheaper than two separate loads stores (alignment quirks notwithstanding).
Interesting idea. That could help with code size too. I'll try it out.


I'm encountering some difficulties implementing this idea.
I want to still keep the per-register structures across the hooks but basically restrict the number
of components in a basic block to an even number of FPRs and GPRs. I tried doing this in COMPONENTS_FOR_BB
but apparently this ended up not saving/restoring some of the registers at all because the components that were
"filtered out" that way still made their way to the bitmap passed into SET_HANDLED_COMPONENTS and so the normal
prologue/epilogue didn't end up saving and restoring them.

I don't want to do it in GET_SEPARATE_COMPONENTS as that doesn't see each basic block.
Is this something DISQUALIFY_COMPONENTS could be used for?

Thanks,
Kyrill


Thanks,
Kyrill



Segher
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]