| Message ID | g4k42whh58.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Mar 07, 2012 at 09:52:51AM +0000, Richard Sandiford wrote: > This patch restores x86_64-linux-gnu bootstrap after my patch for 52372. > Applied as obvious. > > Sorry for the breakage. Was it really necessary to move these out of the global rtx array? Now you completely unnecessarily have 4 new GTY roots with all the overhead it has. Wouldn't just moving their initialization elsewhere be sufficient? > gcc/ > PR middle-end/52515 > * rtl.h (pc_rtx, cc0_rtx, ret_rtx, simple_return_rtx): Add GTY markers. > > Index: gcc/rtl.h > =================================================================== > --- gcc/rtl.h 2012-03-07 09:49:12.000000000 +0000 > +++ gcc/rtl.h 2012-03-07 09:49:12.878790539 +0000 > @@ -2089,10 +2089,10 @@ #define CONST1_RTX(MODE) (const_tiny_rtx > #define CONST2_RTX(MODE) (const_tiny_rtx[2][(int) (MODE)]) > #define CONSTM1_RTX(MODE) (const_tiny_rtx[3][(int) (MODE)]) > > -extern rtx pc_rtx; > -extern rtx cc0_rtx; > -extern rtx ret_rtx; > -extern rtx simple_return_rtx; > +extern GTY(()) rtx pc_rtx; > +extern GTY(()) rtx cc0_rtx; > +extern GTY(()) rtx ret_rtx; > +extern GTY(()) rtx simple_return_rtx; > > /* If HARD_FRAME_POINTER_REGNUM is defined, then a special dummy reg > is used to represent the frame pointer. This is because the Jakub
Jakub Jelinek <jakub@redhat.com> writes: > On Wed, Mar 07, 2012 at 09:52:51AM +0000, Richard Sandiford wrote: >> This patch restores x86_64-linux-gnu bootstrap after my patch for 52372. >> Applied as obvious. >> >> Sorry for the breakage. > > Was it really necessary to move these out of the global rtx array? > Now you completely unnecessarily have 4 new GTY roots with all the overhead > it has. Wouldn't just moving their initialization elsewhere be sufficient? It had to be outside the "global" array, because that's a per-target thing. E.g. MIPS16 and non-MIPS16 have separate target_rtl structures, but ought to have the same pc_rtx (just as they ought to have the same const0_rtx, etc.) I hadn't realised that the overhead of 4 roots was much greater than the overhead of one root pointing to a 4-element array. We could have a new 4-element array if that's a problem. Richard
On Wed, Mar 7, 2012 at 11:11 AM, Richard Sandiford <rdsandiford@googlemail.com> wrote: > Jakub Jelinek <jakub@redhat.com> writes: >> On Wed, Mar 07, 2012 at 09:52:51AM +0000, Richard Sandiford wrote: >>> This patch restores x86_64-linux-gnu bootstrap after my patch for 52372. >>> Applied as obvious. >>> >>> Sorry for the breakage. >> >> Was it really necessary to move these out of the global rtx array? >> Now you completely unnecessarily have 4 new GTY roots with all the overhead >> it has. Wouldn't just moving their initialization elsewhere be sufficient? > > It had to be outside the "global" array, because that's a per-target thing. > E.g. MIPS16 and non-MIPS16 have separate target_rtl structures, but ought > to have the same pc_rtx (just as they ought to have the same const0_rtx, etc.) > > I hadn't realised that the overhead of 4 roots was much greater than the > overhead of one root pointing to a 4-element array. We could have a new > 4-element array if that's a problem. Why can't you put the same RTXen in the per-target rtl structures? > Richard >
Richard Guenther <richard.guenther@gmail.com> writes: > On Wed, Mar 7, 2012 at 11:11 AM, Richard Sandiford > <rdsandiford@googlemail.com> wrote: >> Jakub Jelinek <jakub@redhat.com> writes: >>> On Wed, Mar 07, 2012 at 09:52:51AM +0000, Richard Sandiford wrote: >>>> This patch restores x86_64-linux-gnu bootstrap after my patch for 52372. >>>> Applied as obvious. >>>> >>>> Sorry for the breakage. >>> >>> Was it really necessary to move these out of the global rtx array? >>> Now you completely unnecessarily have 4 new GTY roots with all the overhead >>> it has. Wouldn't just moving their initialization elsewhere be sufficient? >> >> It had to be outside the "global" array, because that's a per-target thing. >> E.g. MIPS16 and non-MIPS16 have separate target_rtl structures, but ought >> to have the same pc_rtx (just as they ought to have the same const0_rtx, etc.) >> >> I hadn't realised that the overhead of 4 roots was much greater than the >> overhead of one root pointing to a 4-element array. We could have a new >> 4-element array if that's a problem. > > Why can't you put the same RTXen in the per-target rtl structures? But where does it stop? Do we move const_tiny_rtx to the target structure too? Logically, the target structure should be for target-specific rtl. Target-independent rtl like constants, (cc0), (pc), etc., should be shared between targets. It seems a shame if GC inefficiencies force us to use a different scheme. Richard
On Wed, Mar 7, 2012 at 11:52 AM, Richard Sandiford <rdsandiford@googlemail.com> wrote: > Richard Guenther <richard.guenther@gmail.com> writes: >> On Wed, Mar 7, 2012 at 11:11 AM, Richard Sandiford >> <rdsandiford@googlemail.com> wrote: >>> Jakub Jelinek <jakub@redhat.com> writes: >>>> On Wed, Mar 07, 2012 at 09:52:51AM +0000, Richard Sandiford wrote: >>>>> This patch restores x86_64-linux-gnu bootstrap after my patch for 52372. >>>>> Applied as obvious. >>>>> >>>>> Sorry for the breakage. >>>> >>>> Was it really necessary to move these out of the global rtx array? >>>> Now you completely unnecessarily have 4 new GTY roots with all the overhead >>>> it has. Wouldn't just moving their initialization elsewhere be sufficient? >>> >>> It had to be outside the "global" array, because that's a per-target thing. >>> E.g. MIPS16 and non-MIPS16 have separate target_rtl structures, but ought >>> to have the same pc_rtx (just as they ought to have the same const0_rtx, etc.) >>> >>> I hadn't realised that the overhead of 4 roots was much greater than the >>> overhead of one root pointing to a 4-element array. We could have a new >>> 4-element array if that's a problem. >> >> Why can't you put the same RTXen in the per-target rtl structures? > > But where does it stop? Do we move const_tiny_rtx to the target > structure too? > > Logically, the target structure should be for target-specific rtl. > Target-independent rtl like constants, (cc0), (pc), etc., should be > shared between targets. It seems a shame if GC inefficiencies > force us to use a different scheme. Ok, if we know for certain this rtl will be never target specific (consider a gcc for multiple targets, sparc and x86_64 for example), then we should have a single structure that contains all those global rtxen. Richard. > Richard
On Wed, Mar 07, 2012 at 11:57:18AM +0100, Richard Guenther wrote: > > Logically, the target structure should be for target-specific rtl. > > Target-independent rtl like constants, (cc0), (pc), etc., should be > > shared between targets. It seems a shame if GC inefficiencies > > force us to use a different scheme. > > Ok, if we know for certain this rtl will be never target specific (consider > a gcc for multiple targets, sparc and x86_64 for example), then we > should have a single structure that contains all those global rtxen. Or perhaps just optimize, say by putting such global rtxs (or tree and other single entry GC roots of the exactly same properties) into named sections (when supported) and letting gengtype create just one root covering the whole section. Jakub
Index: gcc/rtl.h =================================================================== --- gcc/rtl.h 2012-03-07 09:49:12.000000000 +0000 +++ gcc/rtl.h 2012-03-07 09:49:12.878790539 +0000 @@ -2089,10 +2089,10 @@ #define CONST1_RTX(MODE) (const_tiny_rtx #define CONST2_RTX(MODE) (const_tiny_rtx[2][(int) (MODE)]) #define CONSTM1_RTX(MODE) (const_tiny_rtx[3][(int) (MODE)]) -extern rtx pc_rtx; -extern rtx cc0_rtx; -extern rtx ret_rtx; -extern rtx simple_return_rtx; +extern GTY(()) rtx pc_rtx; +extern GTY(()) rtx cc0_rtx; +extern GTY(()) rtx ret_rtx; +extern GTY(()) rtx simple_return_rtx; /* If HARD_FRAME_POINTER_REGNUM is defined, then a special dummy reg is used to represent the frame pointer. This is because the