Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Wed, Nov 30, 2016 at 02:07:58PM +, Kyrill Tkachov wrote: > > On 29/11/16 20:29, Segher Boessenkool wrote: > >Hi James, Kyrill, > > > >On Tue, Nov 29, 2016 at 10:57:33AM +, James Greenhalgh wrote: > >>>+static sbitmap > >>>+aarch64_components_for_bb (basic_block bb) > >>>+{ > >>>+ bitmap in = DF_LIVE_IN (bb); > >>>+ bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; > >>>+ bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; > >>>+ > >>>+ sbitmap components = sbitmap_alloc (V31_REGNUM + 1); > >>>+ bitmap_clear (components); > >>>+ > >>>+ /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ > >>>+ for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) > >>The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're > >>hardcoding > >>where the end of the register file is (does this, for example, fall apart > >>with the SVE work that was recently posted). Something like a > >>LAST_HARDREG_NUM might work? > >Components and registers aren't the same thing (you can have components > >for things that aren't just a register save, e.g. the frame setup, stack > >alignment, save of some non-GPR via a GPR, PIC register setup, etc.) > >The loop here should really only cover the non-volatile registers, and > >there should be some translation from register number to component number > >(it of course is convenient to have a 1-1 translation for the GPRs and > >floating point registers). For rs6000 many things in the backend already > >use non-symbolic numbers for the FPRs and GPRs, so that is easier there. > > Anyway, here's the patch with James's comments implemented. > I've introduced LAST_SAVED_REGNUM which is used to delimit the registers > considered for shrink-wrapping. > > aarch64_process_components is introduced and used to implement the > emit_prologue_components and emit_epilogue_components functions in a single > place. OK. > > Bootstrapped and tested on aarch64-none-linux-gnu. > > Thanks, > Kyrill > > 2016-11-30 Kyrylo Tkachov > > * config/aarch64/aarch64.h (machine_function): Add > reg_is_wrapped_separately field. > * config/aarch64/aarch64.md (LAST_SAVED_REGNUM): Define new constant. > * config/aarch64/aarch64.c (emit_set_insn): Change return type to > rtx_insn *. > (aarch64_save_callee_saves): Don't save registers that are wrapped > separately. > (aarch64_restore_callee_saves): Don't restore registers that are > wrapped separately. > (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, > aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. > (aarch64_get_separate_components): New function. > (aarch64_get_next_set_bit): Likewise. > (aarch64_components_for_bb): Likewise. > (aarch64_disqualify_components): Likewise. > (aarch64_emit_prologue_components): Likewise. > (aarch64_emit_epilogue_components): Likewise. > (aarch64_set_handled_components): Likewise. > (aarch64_process_components): Likewise. > (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, > TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, > TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. > >>>+static void > >>>+aarch64_disqualify_components (sbitmap, edge, sbitmap, bool) > >>>+{ > >>>+} > >>Is there no default "do nothing" hook for this? > >I can make the shrink-wrap code do nothing here if this hook isn't > >defined, if you want? > > I don't mind either way. > If you do it I'll then remove the empty implementation in aarch64. If there is no empty default, this is fine. Thanks, James
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 29/11/16 20:29, Segher Boessenkool wrote: Hi James, Kyrill, On Tue, Nov 29, 2016 at 10:57:33AM +, James Greenhalgh wrote: +static sbitmap +aarch64_components_for_bb (basic_block bb) +{ + bitmap in = DF_LIVE_IN (bb); + bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; + bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; + + sbitmap components = sbitmap_alloc (V31_REGNUM + 1); + bitmap_clear (components); + + /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're hardcoding where the end of the register file is (does this, for example, fall apart with the SVE work that was recently posted). Something like a LAST_HARDREG_NUM might work? Components and registers aren't the same thing (you can have components for things that aren't just a register save, e.g. the frame setup, stack alignment, save of some non-GPR via a GPR, PIC register setup, etc.) The loop here should really only cover the non-volatile registers, and there should be some translation from register number to component number (it of course is convenient to have a 1-1 translation for the GPRs and floating point registers). For rs6000 many things in the backend already use non-symbolic numbers for the FPRs and GPRs, so that is easier there. Anyway, here's the patch with James's comments implemented. I've introduced LAST_SAVED_REGNUM which is used to delimit the registers considered for shrink-wrapping. aarch64_process_components is introduced and used to implement the emit_prologue_components and emit_epilogue_components functions in a single place. Bootstrapped and tested on aarch64-none-linux-gnu. Thanks, Kyrill 2016-11-30 Kyrylo Tkachov * config/aarch64/aarch64.h (machine_function): Add reg_is_wrapped_separately field. * config/aarch64/aarch64.md (LAST_SAVED_REGNUM): Define new constant. * config/aarch64/aarch64.c (emit_set_insn): Change return type to rtx_insn *. (aarch64_save_callee_saves): Don't save registers that are wrapped separately. (aarch64_restore_callee_saves): Don't restore registers that are wrapped separately. (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. (aarch64_get_separate_components): New function. (aarch64_get_next_set_bit): Likewise. (aarch64_components_for_bb): Likewise. (aarch64_disqualify_components): Likewise. (aarch64_emit_prologue_components): Likewise. (aarch64_emit_epilogue_components): Likewise. (aarch64_set_handled_components): Likewise. (aarch64_process_components): Likewise. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. +static void +aarch64_disqualify_components (sbitmap, edge, sbitmap, bool) +{ +} Is there no default "do nothing" hook for this? I can make the shrink-wrap code do nothing here if this hook isn't defined, if you want? I don't mind either way. If you do it I'll then remove the empty implementation in aarch64. Segher commit 194816281ec6da2620bb34c9278ed7edf8bcf0da Author: Kyrylo Tkachov Date: Tue Oct 11 09:25:54 2016 +0100 [AArch64] Separate shrink wrapping hooks implementation diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 82bfe14..48e6e2c 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -1138,7 +1138,7 @@ aarch64_is_extend_from_extract (machine_mode mode, rtx mult_imm, /* Emit an insn that's a simple single-set. Both the operands must be known to be valid. */ -inline static rtx +inline static rtx_insn * emit_set_insn (rtx x, rtx y) { return emit_insn (gen_rtx_SET (x, y)); @@ -3135,6 +3135,9 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, || regno == cfun->machine->frame.wb_candidate2)) continue; + if (cfun->machine->reg_is_wrapped_separately[regno]) + continue; + reg = gen_rtx_REG (mode, regno); offset = start_offset + cfun->machine->frame.reg_offset[regno]; mem = gen_mem_ref (mode, plus_constant (Pmode, stack_pointer_rtx, @@ -3143,6 +3146,7 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, regno2 = aarch64_next_callee_save (regno + 1, limit); if (regno2 <= limit + && !cfun->machine->reg_is_wrapped_separately[regno2] && ((cfun->machine->frame.reg_offset[regno] + UNITS_PER_WORD) == cfun->machine->frame.reg_offset[regno2])) @@ -3191,6 +3195,9 @@ aarch64_restore_callee_saves (machine_mode mode, regno <= limit; regno = aarch64_next_callee_save (regno + 1, limit)) { + if (cfun->machine->reg_is_
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
Hi James, Kyrill, On Tue, Nov 29, 2016 at 10:57:33AM +, James Greenhalgh wrote: > > +static sbitmap > > +aarch64_components_for_bb (basic_block bb) > > +{ > > + bitmap in = DF_LIVE_IN (bb); > > + bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; > > + bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; > > + > > + sbitmap components = sbitmap_alloc (V31_REGNUM + 1); > > + bitmap_clear (components); > > + > > + /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ > > + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) > > The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're hardcoding > where the end of the register file is (does this, for example, fall apart > with the SVE work that was recently posted). Something like a > LAST_HARDREG_NUM might work? Components and registers aren't the same thing (you can have components for things that aren't just a register save, e.g. the frame setup, stack alignment, save of some non-GPR via a GPR, PIC register setup, etc.) The loop here should really only cover the non-volatile registers, and there should be some translation from register number to component number (it of course is convenient to have a 1-1 translation for the GPRs and floating point registers). For rs6000 many things in the backend already use non-symbolic numbers for the FPRs and GPRs, so that is easier there. > > +static void > > +aarch64_disqualify_components (sbitmap, edge, sbitmap, bool) > > +{ > > +} > > Is there no default "do nothing" hook for this? I can make the shrink-wrap code do nothing here if this hook isn't defined, if you want? Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Tue, Nov 29, 2016 at 11:32:41AM +, Kyrill Tkachov wrote: > >>+ > >>+/* Implement TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB. */ > >>+ > >>+static sbitmap > >>+aarch64_components_for_bb (basic_block bb) > >>+{ > >>+ bitmap in = DF_LIVE_IN (bb); > >>+ bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; > >>+ bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; > >>+ > >>+ sbitmap components = sbitmap_alloc (V31_REGNUM + 1); > >>+ bitmap_clear (components); > >>+ > >>+ /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ > >>+ for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) > >>The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're > >>hardcoding > >>where the end of the register file is (does this, for example, fall apart > >>with the SVE work that was recently posted). Something like a > >>LAST_HARDREG_NUM might work? > >> > > > >I think you mean FIRST_PSEUDO_REGISTER. AFAICS the compiler uses > >a loop from 0 to FIRST_PSEUDO_REGISTER to go through the hard registers > >in various places in the midend. > >I'll change it to use that, though if the way to save/restore such new > >registers becomes > >different from the current approach (i.e. perform a DI/DFmode memory op) the > >code in these > >hooks will have to be updated anyway to take it into account. > > > > And actually trying to implement this blows up. The "hard" registers include > CC_REGNUM, which we definitely want to avoid 'saving/restoring'. We really > just want to save the normal register data registers, so is it okay if I > leave it as it is? The prologue/epilogue code already uses V31_REGNUM, so it > would need to change anyway if new registers are added in the future. Well, you could always define a new constant in aarch64.md ? (LAST_SAVED_REGISTER 63) Which would still save hardcoding V31_REGNUM everywhere. And yes, the pro-/epilogue functions could also do with this fix (preapproved). James
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 29/11/16 11:18, Kyrill Tkachov wrote: Hi James, On 29/11/16 10:57, James Greenhalgh wrote: On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote: On 11/11/16 15:31, Kyrill Tkachov wrote: On 11/11/16 10:17, Kyrill Tkachov wrote: On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. And here's a version that explicitly emits pairs. I've looked at assembly codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the original version. I kicked off benchmarks over the weekend to see the effect. Andrew, if you want to try it out (more benchmarking and testing always welcome) this is the one to try. And I discovered over the weekend that gamess and wrf have validation errors. This version runs correctly. SPECINT results were fine though and there is even a small overall gain due to sjeng and omnetpp. However, gobmk still has the regression. I'll rerun SPECFP with this patch (it's really just a small bugfix over the previous version) and get on with analysing gobmk. I have some comments in line, most of which are about hardcoding the maximum register number, but at a high level this looks good to me. Thanks for having a look. I'll respin with the comments addressed and I have a couple of comments inline. Kyrill Thanks, James + +/* Implement TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB. */ + +static sbitmap +aarch64_components_for_bb (basic_block bb) +{ + bitmap in = DF_LIVE_IN (bb); + bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; + bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; + + sbitmap components = sbitmap_alloc (V31_REGNUM + 1); + bitmap_clear (components); + + /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're hardcoding where the end of the register file is (does this, for example, fall apart with the SVE work that was recently posted). Something like a LAST_HARDREG_NUM might work? I think you mean FIRST_PSEUDO_REGISTER. AFAICS the compiler uses a loop from 0 to FIRST_PSEUDO_REGISTER to go through the hard registers in various places in the midend. I'll change it to use that, though if the way to save/restore such new registers becomes different from the current approach (i.e. perform a DI/DFmode memory op) the code in these hooks will have to be updated anyway to take it into account. And actually trying to implement this blows up. The "hard" registers include CC_REGNUM, which we definitely want to avoid 'saving/restoring'. We really just want to save the normal register data registers, so is it okay if I leave it as it is? The prologue/epilogue code already uses V31_REGNUM, so it would need to change anyway if new registers are added in the future. Kyrill +if ((!call_used_regs[regno]) + && (bitmap_bit_p (in, regno) + || bitmap_bit_p (gen, regno) + || bitmap_bit_p (kill, regno))) + bitmap_set_bit (components, regno); + + return components; +} + +/* Implement TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS. + Nothing to do for aarch64. */ + +static void +aarch64_disqualify_components (sbitmap, edge, sbitmap, bool) +{ +} Is there no default "do nothing" hook for this? I don't see one defined anywhere and the documentation for TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS says that if it is defined, all other hooks in the group must be defined. + +/* Return the next set bit in BMP from START onwards. Return the total number + of bits in BMP if no set bit is found at or after START. */ + +static unsigned int +aarch64_get_next_set_bit (sbitmap bmp, unsigned int start) +{ + unsigned int nbits = SBITMAP_SIZE (bmp); + if (start == nbits) +return start; + + gcc_assert (start < nbits); + for (unsigned int i = start; i < nbits; i++) +if (bitmap_bit_p (bmp, i)) + return i; + + return n
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
Hi James, On 29/11/16 10:57, James Greenhalgh wrote: On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote: On 11/11/16 15:31, Kyrill Tkachov wrote: On 11/11/16 10:17, Kyrill Tkachov wrote: On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. And here's a version that explicitly emits pairs. I've looked at assembly codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the original version. I kicked off benchmarks over the weekend to see the effect. Andrew, if you want to try it out (more benchmarking and testing always welcome) this is the one to try. And I discovered over the weekend that gamess and wrf have validation errors. This version runs correctly. SPECINT results were fine though and there is even a small overall gain due to sjeng and omnetpp. However, gobmk still has the regression. I'll rerun SPECFP with this patch (it's really just a small bugfix over the previous version) and get on with analysing gobmk. I have some comments in line, most of which are about hardcoding the maximum register number, but at a high level this looks good to me. Thanks for having a look. I'll respin with the comments addressed and I have a couple of comments inline. Kyrill Thanks, James + +/* Implement TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB. */ + +static sbitmap +aarch64_components_for_bb (basic_block bb) +{ + bitmap in = DF_LIVE_IN (bb); + bitmap gen = &DF_LIVE_BB_INFO (bb)->gen; + bitmap kill = &DF_LIVE_BB_INFO (bb)->kill; + + sbitmap components = sbitmap_alloc (V31_REGNUM + 1); + bitmap_clear (components); + + /* GPRs are used in a bb if they are in the IN, GEN, or KILL sets. */ + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) The use of R0_REGNUM and V31_REGNUM scare me a little bit, as we're hardcoding where the end of the register file is (does this, for example, fall apart with the SVE work that was recently posted). Something like a LAST_HARDREG_NUM might work? I think you mean FIRST_PSEUDO_REGISTER. AFAICS the compiler uses a loop from 0 to FIRST_PSEUDO_REGISTER to go through the hard registers in various places in the midend. I'll change it to use that, though if the way to save/restore such new registers becomes different from the current approach (i.e. perform a DI/DFmode memory op) the code in these hooks will have to be updated anyway to take it into account. +if ((!call_used_regs[regno]) + && (bitmap_bit_p (in, regno) + || bitmap_bit_p (gen, regno) + || bitmap_bit_p (kill, regno))) + bitmap_set_bit (components, regno); + + return components; +} + +/* Implement TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS. + Nothing to do for aarch64. */ + +static void +aarch64_disqualify_components (sbitmap, edge, sbitmap, bool) +{ +} Is there no default "do nothing" hook for this? I don't see one defined anywhere and the documentation for TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS says that if it is defined, all other hooks in the group must be defined. + +/* Return the next set bit in BMP from START onwards. Return the total number + of bits in BMP if no set bit is found at or after START. */ + +static unsigned int +aarch64_get_next_set_bit (sbitmap bmp, unsigned int start) +{ + unsigned int nbits = SBITMAP_SIZE (bmp); + if (start == nbits) +return start; + + gcc_assert (start < nbits); + for (unsigned int i = start; i < nbits; i++) +if (bitmap_bit_p (bmp, i)) + return i; + + return nbits; +} + +/* Implement TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS. */ + +static void +aarch64_emit_prologue_components (sbitmap components) +{ + rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed +? HARD_FRAME_POINTER_REGNUM +: STACK_POINTER_REGNUM); + + unsigned total_bits = SBITMAP_SIZE (components); Would this be clearer called last_regno ? + u
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote: > > On 11/11/16 15:31, Kyrill Tkachov wrote: > > > >On 11/11/16 10:17, Kyrill Tkachov wrote: > >> > >>On 10/11/16 23:39, Segher Boessenkool wrote: > >>>On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: > On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov > >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% > > Wow, this looks really good. Thank you for implementing this. If I > get some time I am going to try it out on other processors than A72 > but I doubt I have time any time soon. > >>>I'd love to hear what causes the slowdown for gobmk as well, btw. > >> > >>I haven't yet gotten a direct answer for that (through performance analysis > >>tools) but I have noticed that load/store pairs are not generated as > >>aggressively as I hoped. They are being merged by the sched fusion pass > >>and peepholes (which runs after this) but it still misses cases. I've > >>hacked the SWS hooks to generate pairs explicitly and that increases the > >>number of pairs and helps code size to boot. It complicates the logic of > >>the hooks a bit but not too much. > >> > >>I'll make those changes and re-benchmark, hopefully that > >>will help performance. > >> > > > >And here's a version that explicitly emits pairs. I've looked at assembly > >codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the > >original version. I kicked off benchmarks over the weekend to see the > >effect. Andrew, if you want to try it out (more benchmarking and testing > >always welcome) this is the one to try. > > > > And I discovered over the weekend that gamess and wrf have validation errors. > This version runs correctly. SPECINT results were fine though and there is > even a small overall gain due to sjeng and omnetpp. However, gobmk still has > the regression. I'll rerun SPECFP with this patch (it's really just a small > bugfix over the previous version) and get on with analysing gobmk. I have some comments in line, most of which are about hardcoding the maximum register number, but at a high level this looks good to me. Thanks, James > 2016-11-11 Kyrylo Tkachov > > * config/aarch64/aarch64.h (machine_function): Add > reg_is_wrapped_separately field. > * config/aarch64/aarch64.c (emit_set_insn): Change return type to > rtx_insn *. > (aarch64_save_callee_saves): Don't save registers that are wrapped > separately. > (aarch64_restore_callee_saves): Don't restore registers that are > wrapped separately. > (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, > aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. > (aarch64_get_separate_components): New function. > (aarch64_get_next_set_bit): Likewise. > (aarch64_components_for_bb): Likewise. > (aarch64_disqualify_components): Likewise. > (aarch64_emit_prologue_components): Likewise. > (aarch64_emit_epilogue_components): Likewise. > (aarch64_set_handled_components): Likewise. > (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, > TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, > TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. > > commit 06ac3c30d8aa38781ee9019e60a5fcf727b85231 > Author: Kyrylo Tkachov > Date: Tue Oct 11 09:25:54 2016 +0100 > > [AArch64] Separate shrink wrapping hooks implementation > > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > index 325e725..2d33ef6 100644 > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -1138,7 +1138,7 @@ aarch64_is_extend_from_extract (machine_mode mode, rtx > mult_imm, > > /* Emit an insn that's a simple single-set. Both the operands must be > known to be valid. */ > -inline static rtx > +inline static rtx_insn * > emit_set_insn (rtx x, rtx y) > { >return emit_insn (gen_rtx_SET (x, y)); > @@ -3135,6 +3135,9 @@ aarch64_save_callee_saves (machine_mode mode, > HOST_WIDE_INT start_offset, > || regno == cfun->machine->frame.wb_candidate2)) > continue; > > + if (cfun->machine->reg_is_wrapped_separately[regno]) > + continue; > + >reg = gen_rtx_REG (mode, regno); >offset = start_offset + cfun->machine->frame.reg_offset[regno]; >mem = gen_mem_ref (mode, plus_constant (Pmode, stack_pointer_rtx, > @@ -3143,6 +3146,7 @@ aarch64_save_callee_saves (machine_mode mode, > HOST_WIDE_INT start_offset, >regno2 = aarch64_next_callee_save (regno + 1, limit); > >if (regno2 <= limit > + && !cfun->machine->reg_is_wrapped_separately[regno2] > && (
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 18/11/16 12:50, Segher Boessenkool wrote: On Fri, Nov 18, 2016 at 09:29:13AM +, Kyrill Tkachov wrote: So your COMPONENTS_FOR_BB returns both components in a pair whenever one of those is needed? That should work afaics. I mean I still want to have one component per register and since emit_{prologue,epilogue}_components knows how to form pairs from the components passed down to it I just need to restrict the number of components in any particular basic block to an even number. So say a function can wrap 5 registers: x22,x23,x24,x25,x26. I want get_separate_components to return 5 components since in that hook we don't know how these registers are distributed across each basic block. components_for_bb has that information. In components_for_bb I want to restrict the components for a basic block to an even number, so if normally all 5 registers would be valid for wrapping in that bb I'd only choose 4 so I could form 2 pairs. But selecting only 4 of the 5 registers, say only x22,x23,x24,x25 leads to x26 not being saved or restored at all, even during the normal prologue and epilogue because x26 was marked as a component in components_for_bb and therefore omitted from the prologue and epilogue. So I'm thinking x26 should be removed from the wrappable components of a basic block by disqualify_components. I'm trying that approach now. My suggestion was, in components_for_bb, whenever you mark x22 as needed you also mark x23 as needed, and whenever you mark x23 as needed you also mark x22. I think this is a lot simpler? But then we'd have cases where we're saving and restoring x23 even when it's not necessary. In any case, I tried it out and it didn't fix the gobmk issue, though it did reduce the code size increase somewhat. With the patch already posted at [1] the net result is still positive on both SPECINT and SPECFP. I also ran the numbers on a Cortex-A57. The changes are less pronounced with SPECINT being neutral (gobmk shows only a 0.8% regression) and SPECFP having a small improvement, due to povray improving by 2.9%. Thanks, Kyrill [1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01352.html Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Fri, Nov 18, 2016 at 09:29:13AM +, Kyrill Tkachov wrote: > >So your COMPONENTS_FOR_BB returns both components in a pair whenever one > >of those is needed? That should work afaics. > > I mean I still want to have one component per register and since > emit_{prologue,epilogue}_components knows how to form pairs from the > components passed down to it I just need to restrict the number of > components in any particular basic block to an even number. > So say a function can wrap 5 registers: x22,x23,x24,x25,x26. > I want get_separate_components to return 5 components since in that hook > we don't know how these registers are distributed across each basic block. > components_for_bb has that information. > In components_for_bb I want to restrict the components for a basic block to > an even number, so if normally all 5 registers would be valid for wrapping > in that bb I'd only choose 4 so I could form 2 pairs. But selecting only 4 > of the 5 registers, say only x22,x23,x24,x25 leads to x26 not being saved > or restored at all, even during the normal prologue and epilogue because > x26 was marked as a component in components_for_bb and therefore omitted > from > the prologue and epilogue. > So I'm thinking x26 should be removed from the wrappable components of > a basic block by disqualify_components. I'm trying that approach now. My suggestion was, in components_for_bb, whenever you mark x22 as needed you also mark x23 as needed, and whenever you mark x23 as needed you also mark x22. I think this is a lot simpler? Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 17/11/16 17:45, Segher Boessenkool wrote: On Thu, Nov 17, 2016 at 04:50:46PM +, Kyrill Tkachov wrote: 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 So your COMPONENTS_FOR_BB returns both components in a pair whenever one of those is needed? That should work afaics. I mean I still want to have one component per register and since emit_{prologue,epilogue}_components knows how to form pairs from the components passed down to it I just need to restrict the number of components in any particular basic block to an even number. So say a function can wrap 5 registers: x22,x23,x24,x25,x26. I want get_separate_components to return 5 components since in that hook we don't know how these registers are distributed across each basic block. components_for_bb has that information. In components_for_bb I want to restrict the components for a basic block to an even number, so if normally all 5 registers would be valid for wrapping in that bb I'd only choose 4 so I could form 2 pairs. But selecting only 4 of the 5 registers, say only x22,x23,x24,x25 leads to x26 not being saved or restored at all, even during the normal prologue and epilogue because x26 was marked as a component in components_for_bb and therefore omitted from the prologue and epilogue. So I'm thinking x26 should be removed from the wrappable components of a basic block by disqualify_components. I'm trying that approach now. Thanks, Kyrill 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 am not sure what this means? "filtered out"? Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Thu, Nov 17, 2016 at 04:50:46PM +, Kyrill Tkachov wrote: > >>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 So your COMPONENTS_FOR_BB returns both components in a pair whenever one of those is needed? That should work afaics. > 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 am not sure what this means? "filtered out"? Segher
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 +, 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: ldpx21, x22, [sp, 16] ldpx23, x24, [sp, 32] ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx30, [sp, 80] ldpx19, x20, [sp], 112 ret and I see this becoming (among numerous other changes in the function): .L69: ldpx21, x22, [sp, 16] ldrx24, [sp, 40] .L43: ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx23, [sp, 32] ldrx30, [sp, 80] ldpx19, 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
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 17/11/16 15:01, Segher Boessenkool wrote: On Thu, Nov 17, 2016 at 02:55:20PM +, Kyrill Tkachov wrote: 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. I meant frame pointer, not floating point :-) Ah :) HARD_FRAME_POINTER is wrapped with -fomit-frame-pointer but we don't touch the stack pointer (SP) in any case. Kyrill Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Thu, Nov 17, 2016 at 02:55:20PM +, Kyrill Tkachov wrote: > >>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. I meant frame pointer, not floating point :-) Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 17/11/16 14:44, Segher Boessenkool wrote: Hi Kyrill, On Thu, Nov 17, 2016 at 02:22:08PM +, 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: ldpx21, x22, [sp, 16] ldpx23, x24, [sp, 32] ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx30, [sp, 80] ldpx19, x20, [sp], 112 ret and I see this becoming (among numerous other changes in the function): .L69: ldpx21, x22, [sp, 16] ldrx24, [sp, 40] .L43: ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx23, [sp, 32] ldrx30, [sp, 80] ldpx19, 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. Thanks, Kyrill Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
Hi Kyrill, On Thu, Nov 17, 2016 at 02:22:08PM +, 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. > 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? > 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: > ldpx21, x22, [sp, 16] > ldpx23, x24, [sp, 32] > ldpx25, x26, [sp, 48] > ldpx27, x28, [sp, 64] > ldrx30, [sp, 80] > ldpx19, x20, [sp], 112 > ret > > and I see this becoming (among numerous other changes in the function): > > .L69: > ldpx21, x22, [sp, 16] > ldrx24, [sp, 40] > .L43: > ldpx25, x26, [sp, 48] > ldpx27, x28, [sp, 64] > ldrx23, [sp, 32] > ldrx30, [sp, 80] > ldpx19, 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. Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 14/11/16 14:25, Kyrill Tkachov wrote: On 11/11/16 15:31, Kyrill Tkachov wrote: On 11/11/16 10:17, Kyrill Tkachov wrote: On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. And here's a version that explicitly emits pairs. I've looked at assembly codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the original version. I kicked off benchmarks over the weekend to see the effect. Andrew, if you want to try it out (more benchmarking and testing always welcome) this is the one to try. And I discovered over the weekend that gamess and wrf have validation errors. This version runs correctly. SPECINT results were fine though and there is even a small overall gain due to sjeng and omnetpp. However, gobmk still has the regression. I'll rerun SPECFP with this patch (it's really just a small bugfix over the previous version) and get on with analysing gobmk. 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). Branch mispredicts also go up a bit but not as much as icache misses. 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. 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: ldpx21, x22, [sp, 16] ldpx23, x24, [sp, 32] ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx30, [sp, 80] ldpx19, x20, [sp], 112 ret and I see this becoming (among numerous other changes in the function): .L69: ldpx21, x22, [sp, 16] ldrx24, [sp, 40] .L43: ldpx25, x26, [sp, 48] ldpx27, x28, [sp, 64] ldrx23, [sp, 32] ldrx30, [sp, 80] ldpx19, 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. Given that there is an overall gain is this ok for trunk? https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01352.html Thanks, Kyrill 2016-11-11 Kyrylo Tkachov * config/aarch64/aarch64.h (machine_function): Add reg_is_wrapped_separately field. * config/aarch64/aarch64.c (emit_set_insn): Change return type to rtx_insn *. (aarch64_save_callee_saves): Don't save registers that are wrapped separately. (aarch64_restore_callee_saves): Don't restore registers that are wrapped separately. (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. (aarch64_get_separate_components): New function. (aarch64_get_next_set_bit): Likewise. (aarch64_components_for_bb): Likewise. (aarch64_disqualify_components): Likewise. (aarch64_emit_prologue_components): Likewise. (aarch64_emit_epilogue_components): Likewise. (aarch64_set_handled_components): Likewise. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 11/11/16 15:31, Kyrill Tkachov wrote: On 11/11/16 10:17, Kyrill Tkachov wrote: On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. And here's a version that explicitly emits pairs. I've looked at assembly codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the original version. I kicked off benchmarks over the weekend to see the effect. Andrew, if you want to try it out (more benchmarking and testing always welcome) this is the one to try. And I discovered over the weekend that gamess and wrf have validation errors. This version runs correctly. SPECINT results were fine though and there is even a small overall gain due to sjeng and omnetpp. However, gobmk still has the regression. I'll rerun SPECFP with this patch (it's really just a small bugfix over the previous version) and get on with analysing gobmk. Thanks, Kyrill 2016-11-11 Kyrylo Tkachov * config/aarch64/aarch64.h (machine_function): Add reg_is_wrapped_separately field. * config/aarch64/aarch64.c (emit_set_insn): Change return type to rtx_insn *. (aarch64_save_callee_saves): Don't save registers that are wrapped separately. (aarch64_restore_callee_saves): Don't restore registers that are wrapped separately. (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. (aarch64_get_separate_components): New function. (aarch64_get_next_set_bit): Likewise. (aarch64_components_for_bb): Likewise. (aarch64_disqualify_components): Likewise. (aarch64_emit_prologue_components): Likewise. (aarch64_emit_epilogue_components): Likewise. (aarch64_set_handled_components): Likewise. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. commit 06ac3c30d8aa38781ee9019e60a5fcf727b85231 Author: Kyrylo Tkachov Date: Tue Oct 11 09:25:54 2016 +0100 [AArch64] Separate shrink wrapping hooks implementation diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 325e725..2d33ef6 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -1138,7 +1138,7 @@ aarch64_is_extend_from_extract (machine_mode mode, rtx mult_imm, /* Emit an insn that's a simple single-set. Both the operands must be known to be valid. */ -inline static rtx +inline static rtx_insn * emit_set_insn (rtx x, rtx y) { return emit_insn (gen_rtx_SET (x, y)); @@ -3135,6 +3135,9 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, || regno == cfun->machine->frame.wb_candidate2)) continue; + if (cfun->machine->reg_is_wrapped_separately[regno]) + continue; + reg = gen_rtx_REG (mode, regno); offset = start_offset + cfun->machine->frame.reg_offset[regno]; mem = gen_mem_ref (mode, plus_constant (Pmode, stack_pointer_rtx, @@ -3143,6 +3146,7 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, regno2 = aarch64_next_callee_save (regno + 1, limit); if (regno2 <= limit + && !cfun->machine->reg_is_wrapped_separately[regno2] && ((cfun->machine->frame.reg_offset[regno] + UNITS_PER_WORD) == cfun->machine->frame.reg_offset[regno2])) @@ -3191,6 +3195,9 @@ aarch64_restore_callee_saves (machine_mode mode, regno <= limit; regno = aarch64_next_callee_save (regno + 1, limit)) { + if (cfun->machine->reg_is_wrapped_separately[regno]) + continue; + rtx reg, mem; if (skip_wb @@ -3205,6 +3212,7 @@ aarch64_restore_callee_saves (machine_mode mode, regno2 = aarch64_next_callee_save (regno + 1, limit);
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 11/11/16 10:17, Kyrill Tkachov wrote: On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. And here's a version that explicitly emits pairs. I've looked at assembly codegen on SPEC2006 and it generates quite a few more LDP/STP pairs than the original version. I kicked off benchmarks over the weekend to see the effect. Andrew, if you want to try it out (more benchmarking and testing always welcome) this is the one to try. Thanks, Kyrill Thanks, Kyrill Segher commit bedb71d6f6f772eed33ba35e93cc4104326675da Author: Kyrylo Tkachov Date: Tue Oct 11 09:25:54 2016 +0100 [AArch64] Separate shrink wrapping hooks implementation diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 325e725..15b5bdf 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -1138,7 +1138,7 @@ aarch64_is_extend_from_extract (machine_mode mode, rtx mult_imm, /* Emit an insn that's a simple single-set. Both the operands must be known to be valid. */ -inline static rtx +inline static rtx_insn * emit_set_insn (rtx x, rtx y) { return emit_insn (gen_rtx_SET (x, y)); @@ -3135,6 +3135,9 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, || regno == cfun->machine->frame.wb_candidate2)) continue; + if (cfun->machine->reg_is_wrapped_separately[regno]) + continue; + reg = gen_rtx_REG (mode, regno); offset = start_offset + cfun->machine->frame.reg_offset[regno]; mem = gen_mem_ref (mode, plus_constant (Pmode, stack_pointer_rtx, @@ -3143,6 +3146,7 @@ aarch64_save_callee_saves (machine_mode mode, HOST_WIDE_INT start_offset, regno2 = aarch64_next_callee_save (regno + 1, limit); if (regno2 <= limit + && !cfun->machine->reg_is_wrapped_separately[regno2] && ((cfun->machine->frame.reg_offset[regno] + UNITS_PER_WORD) == cfun->machine->frame.reg_offset[regno2])) @@ -3191,6 +3195,9 @@ aarch64_restore_callee_saves (machine_mode mode, regno <= limit; regno = aarch64_next_callee_save (regno + 1, limit)) { + if (cfun->machine->reg_is_wrapped_separately[regno]) + continue; + rtx reg, mem; if (skip_wb @@ -3205,6 +3212,7 @@ aarch64_restore_callee_saves (machine_mode mode, regno2 = aarch64_next_callee_save (regno + 1, limit); if (regno2 <= limit + && !cfun->machine->reg_is_wrapped_separately[regno2] && ((cfun->machine->frame.reg_offset[regno] + UNITS_PER_WORD) == cfun->machine->frame.reg_offset[regno2])) { @@ -3224,6 +3232,273 @@ aarch64_restore_callee_saves (machine_mode mode, } } +static inline bool +offset_9bit_signed_unscaled_p (machine_mode mode ATTRIBUTE_UNUSED, + HOST_WIDE_INT offset) +{ + return offset >= -256 && offset < 256; +} + +static inline bool +offset_12bit_unsigned_scaled_p (machine_mode mode, HOST_WIDE_INT offset) +{ + return (offset >= 0 + && offset < 4096 * GET_MODE_SIZE (mode) + && offset % GET_MODE_SIZE (mode) == 0); +} + +bool +aarch64_offset_7bit_signed_scaled_p (machine_mode mode, HOST_WIDE_INT offset) +{ + return (offset >= -64 * GET_MODE_SIZE (mode) + && offset < 64 * GET_MODE_SIZE (mode) + && offset % GET_MODE_SIZE (mode) == 0); +} + +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */ + +static sbitmap +aarch64_get_separate_components (void) +{ + aarch64_layout_frame (); + + sbitmap components = sbitmap_alloc (V31_REGNUM + 1); + bitmap_clear (components); + + /* The registers we need saved to the frame. */ + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) +if (aarch64_register_saved_on_entry (regno)) + { + HOST_WIDE_INT offset = cfun->machine->frame.reg_offset[regno]; + if (!frame_pointer_needed) + offset += cfun->machine->frame.frame_size + - cfun->machine->frame.hard_fp_offset; + /* Check that we can access the st
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 10/11/16 23:39, Segher Boessenkool wrote: On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. I haven't yet gotten a direct answer for that (through performance analysis tools) but I have noticed that load/store pairs are not generated as aggressively as I hoped. They are being merged by the sched fusion pass and peepholes (which runs after this) but it still misses cases. I've hacked the SWS hooks to generate pairs explicitly and that increases the number of pairs and helps code size to boot. It complicates the logic of the hooks a bit but not too much. I'll make those changes and re-benchmark, hopefully that will help performance. Thanks, Kyrill Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: > On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov > > 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% > > > Wow, this looks really good. Thank you for implementing this. If I > get some time I am going to try it out on other processors than A72 > but I doubt I have time any time soon. I'd love to hear what causes the slowdown for gobmk as well, btw. Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov wrote: > Hi all, > > This patch implements the new separate shrink-wrapping hooks for aarch64. > In separate shrink wrapping (as I understand it) we consider each register > save/restore as > a 'component' that can be performed independently of the other save/restores > in the prologue/epilogue > and can be moved outside the prologue/epilogue and instead performed only in > the basic blocks where it's > actually needed. This allows us to avoid saving and restoring registers on > execution paths where a register > might not be needed. > > In the most general form a 'component' can be any operation that the > prologue/epilogue performs, for example > stack adjustment. But in this patch we only consider callee-saved register > save/restores as components. > The code is in many ways similar to the powerpc implementation of the hooks. > > The hooks implemented are: > * TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Returns a bitmap containing a > bit for each register that should > be considered a 'component' i.e. its save/restore should be separated from > the prologue and epilogue and placed > at the basic block where it's needed. > > * TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Determine for a given basic block > which 'component' registers it needs. > This is determined through dataflow. If a component register is in the > IN,GEN or KILL sets for the basic block > it's considered as needed and marked as such in the bitmap. > > * TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS and > TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Given a bitmap > of component registers emits the save or restore code for them. > > * TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Given a bitmap of component > registers record in the backend that > the register is shrink-wrapped using this approach and that the normal > prologue and epilogue expansion code > should not emit code for them. This is done similarly to powerpc by defining > a bool array in machine_function > where we record whether each register is separately shrink-wrapped. The > prologue and epilogue expansion code > (through aarch64_save_callee_saves and aarch64_restore_callee_saves) is > updated to not emit save/restores for > these registers if they appear in that array. > > Our prologue and epilogue code has a lot of intricate logic to perform stack > adjustments using the writeback > forms of the load/store instructions. Separately shrink-wrapping those > registers marked for writeback > (cfun->machine->frame.wb_candidate1 and cfun->machine->frame.wb_candidate2) > broke that codegen and I had to > emit an explicit stack adjustment instruction that created ugly > prologue/epilogue sequences. So this patch > is conservative and doesn't allow shrink-wrapping of the registers marked > for writeback. Maybe in the future > we can relax it (for example allow wrapping of one of the two writeback > registers if the writeback amount > can be encoded in a single-register writeback store/load) but given the > development stage of GCC I thought > I'd play it safe. > > 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% Wow, this looks really good. Thank you for implementing this. If I get some time I am going to try it out on other processors than A72 but I doubt I have time any time soon. Thanks, Andrew > > I'll be re-running the benchmarks with Segher's recent patch [1] to see if > they fix the regression > and if it does I think this can go in. > > [1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00889.html > > Bootstrapped and tested on aarch64-none-linux-gnu. > > Thanks, > Kyrill > > 2016-11-10 Kyrylo Tkachov > > * config/aarch64/aarch64.h (machine_function): Add > reg_is_wrapped_separately field. > * config/aarch64/aarch64.c (emit_set_insn): Change return type to > rtx_insn *. > (aarch64_save_callee_saves): Don't save registers that are wrapped > separately. > (aarch64_restore_callee_saves): Don't restore registers that are > wrapped separately. > (offset_9bit_signed_unscaled_p, offset_12bit_unsigned_scaled_p, > aarch64_offset_7bit_signed_scaled_p): Move earlier in the file. > (aarch64_get_separate_components): New function. > (aarch64_components_for_bb): Likewise. > (aarch64_disqualify_components): Likewise. > (aarch64_emit_prologue_components): Likewise. > (aarch64_emit_epilogue_components): Likewise. > (aarch64_set_handled_components): Likewise. > (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, > TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, > TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, > TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
On 10/11/16 16:26, Segher Boessenkool wrote: Hi! Hi, Great to see this. Just a few comments... On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote: +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */ + +static sbitmap +aarch64_get_separate_components (void) +{ + /* Calls to alloca further extend the stack frame and it can be messy to + figure out the location of the stack slots for each register. + For now be conservative. */ + if (cfun->calls_alloca) +return NULL; The generic code already disallows functions with alloca (in try_shrink_wrapping_separate). Ok, I'll remove this. +static void +aarch64_emit_prologue_components (sbitmap components) +{ + rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed +? HARD_FRAME_POINTER_REGNUM +: STACK_POINTER_REGNUM); + + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) +if (bitmap_bit_p (components, regno)) + { + rtx reg = gen_rtx_REG (Pmode, regno); + HOST_WIDE_INT offset = cfun->machine->frame.reg_offset[regno]; + if (!frame_pointer_needed) + offset += cfun->machine->frame.frame_size + - cfun->machine->frame.hard_fp_offset; + rtx addr = plus_constant (Pmode, ptr_reg, offset); + rtx mem = gen_frame_mem (Pmode, addr); + + RTX_FRAME_RELATED_P (emit_move_insn (mem, reg)) = 1; + } +} I think you should emit the CFI notes here directly, just like for the epilogue components. The prologue code in expand_prologue doesn't attach any explicit notes, so I didn't want to deviate from that. Looking at the powerpc implementation, would that be a REG_CFA_OFFSET with the (SET (mem) (reg)) expression for saving the reg? Thanks, Kyrill Segher
Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation
Hi! Great to see this. Just a few comments... On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote: > +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */ > + > +static sbitmap > +aarch64_get_separate_components (void) > +{ > + /* Calls to alloca further extend the stack frame and it can be messy to > + figure out the location of the stack slots for each register. > + For now be conservative. */ > + if (cfun->calls_alloca) > +return NULL; The generic code already disallows functions with alloca (in try_shrink_wrapping_separate). > +static void > +aarch64_emit_prologue_components (sbitmap components) > +{ > + rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed > + ? HARD_FRAME_POINTER_REGNUM > + : STACK_POINTER_REGNUM); > + > + for (unsigned regno = R0_REGNUM; regno <= V31_REGNUM; regno++) > +if (bitmap_bit_p (components, regno)) > + { > + rtx reg = gen_rtx_REG (Pmode, regno); > + HOST_WIDE_INT offset = cfun->machine->frame.reg_offset[regno]; > + if (!frame_pointer_needed) > + offset += cfun->machine->frame.frame_size > + - cfun->machine->frame.hard_fp_offset; > + rtx addr = plus_constant (Pmode, ptr_reg, offset); > + rtx mem = gen_frame_mem (Pmode, addr); > + > + RTX_FRAME_RELATED_P (emit_move_insn (mem, reg)) = 1; > + } > +} I think you should emit the CFI notes here directly, just like for the epilogue components. Segher