Re: bootstrap on powerpc fails
> Figures? Tree checking is not cheap with GCC 4.x either. Here are mine (Athlon64 2.4 GHz, 1 GB, c,c++,objc,obj-c++,java,fortran,ada): gcc version 4.3.0 20061103 (experimental) assert,runtime (aka release): 115 min assert,runtime,misc:176 min assert,runtime,misc,gc: 186 min assert,runtime,misc,gc,tree:203 min assert,runtime,misc,gc,tree,rtl,rtlflag 266 min So I was wrong, tree checking is still relatively cheap; misc and rtl are not. -- Eric Botcazou
Re: bootstrap on powerpc fails
> I can sympathize with that, I have a slightly different problem. Right > now there are some java test that time-out 10x on solaris2.10. I run four > passes of the testsuite with different options each time, so that 40 > timeouts. (This is without any extra RTL checking turned on.) At 5 > minutes each it adds up fast! > http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00294.html This happened at some point during 4.1 development too. It turned out to be a code generation bug that was butchering the PTHREAD_* initializer macros. -- Eric Botcazou
Re: bootstrap on powerpc fails
Maybe in another six years cpu improvements will outpace gcc bootstrap times enough to reconsider. We'll have 60 cores per CPU, and 1 minute after invoking "make" we'll be cursing how much it takes for insn-attrtab.c to finish compiling. :-) Paolo
Re: bootstrap on powerpc fails
On Tue, 7 Nov 2006, Mark Mitchell wrote: > > I object. > > Me too. > > I'm a big proponent of testing, but I do think there should be some > bang/buck tradeoff. (For example, we have tests in the GCC testsuite > that take several minutes to run -- but never fail. I doubt these tests > are actually buying us a factor of several hundred more quality quanta > over the average test.) Machine time is cheap, but human time is not, > and I know that for me the testsuite-latency time is a factor in how > many patches I can write, because I'm not great at keeping track of > multiple patches at once. > Mark Mitchell I can sympathize with that, I have a slightly different problem. Right now there are some java test that time-out 10x on solaris2.10. I run four passes of the testsuite with different options each time, so that 40 timeouts. (This is without any extra RTL checking turned on.) At 5 minutes each it adds up fast! http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00294.html Maybe in another six years cpu improvements will outpace gcc bootstrap times enough to reconsider. In the mean time, I would encourage anyone patching middle-end RTL files and especially backend target files to try using RTL checking to validate their patches if they have enough spare cpu and time. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: bootstrap on powerpc fails
On Tue, 7 Nov 2006, Mike Stump wrote: > On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote: > > Perhaps we could take a second look at this decision? The average > > system has increased in speed many times since then. (Although > > sometimes I feel like bootstrapping time has increased at an even > > greater pace than chip improvements over the years. :-) > > Odd. You must not build java. I *always* build java unless it's broken for some reason. I don't see what that has to do with it. Bootstrap times are increasing for me over the years regardless of whether I include java or not. This happens largely because more code is added to GCC, not always because compile-times get worse. Or e.g. top level bootstrap recompiles all the support libraries at each stage, whereas before it didn't. > I'd rather have one person that tests it occasionally and save the CPU > cycles of all the rest of the folks, more scalable. That doesn't give us the full advantage because (unlike tree checking) RTL checking errors are often very specific to the target implementation. So having a few of us use it doesn't help make sure the other targets also pass. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: bootstrap on powerpc fails
> Because it takes a LONG time. Figures? Tree checking is not cheap with GCC 4.x either. -- Eric Botcazou
Re: bootstrap on powerpc fails
On Tue, Nov 07, 2006 at 11:36:00PM -0600, Peter Bergner wrote:
> The parallel that is causing the ICE is a store with update RTL insn.
> It seems like we should detect that and reach into the parallel and
> grab the actual store insn. I'll look into adding that.
I'm testing the patch below. It finished bootstrapping fine, I
just need to run the test suite now.
Peter
Index: rs6000.c
===
--- rs6000.c(revision 118396)
+++ rs6000.c(working copy)
@@ -674,6 +674,7 @@
static bool is_cracked_insn (rtx);
static bool is_branch_slot_insn (rtx);
static bool is_load_insn (rtx);
+static rtx get_store_dest (rtx pat);
static bool is_store_insn (rtx);
static bool set_to_load_agen (rtx,rtx);
static bool adjacent_mem_locations (rtx,rtx);
@@ -16952,9 +16953,9 @@
adjacent_mem_locations (rtx insn1, rtx insn2)
{
- rtx a = SET_DEST (PATTERN (insn1));
- rtx b = SET_DEST (PATTERN (insn2));
-
+ rtx a = get_store_dest (PATTERN (insn1));
+ rtx b = get_store_dest (PATTERN (insn2));
+
if ((GET_CODE (XEXP (a, 0)) == REG
|| (GET_CODE (XEXP (a, 0)) == PLUS
&& GET_CODE (XEXP (XEXP (a, 0), 1)) == CONST_INT))
@@ -17208,6 +17209,28 @@
return is_store_insn1 (PATTERN (insn));
}
+/* Return the dest of a store insn. */
+
+static rtx
+get_store_dest (rtx pat)
+{
+ gcc_assert (is_store_insn1 (pat));
+
+ if (GET_CODE (pat) == SET)
+return SET_DEST (pat);
+ else if (GET_CODE (pat) == PARALLEL)
+{
+ int i;
+
+ for (i = 0; i < XVECLEN (pat, 0); i++)
+ if (is_store_insn1 (XVECEXP (pat, 0, i)))
+ return XVECEXP (pat, 0, i);
+}
+ /* We shouldn't get here, because we should have either a simple
+ store insn or a store with update which are covered above. */
+ gcc_assert (0);
+}
+
/* Returns whether the dependence between INSN and NEXT is considered
costly by the given target. */
Re: bootstrap on powerpc fails
On Tue, 2006-11-07 at 17:30 -0500, Andrew Pinski wrote:
> >
> > Bootstrap off the trunk on powerpc-linux fails currently with:
> >
> > /cvs/gcc-svn/trunk/gcc/libgcov.c: In function =E2=80=98__gcov_execl=E2=80=
> > =99:
> > /cvs/gcc-svn/trunk/gcc/libgcov.c:796: internal compiler error: RTL check: e=
> > xpected code 'set' or 'clobber', have 'parallel' in adjacent_mem_locations,=
> > at config/rs6000/rs6000.c:16955
> >
> > Is this already known or should I file a bugreport? I haven't tested
> > for over a week, so do not know when this was introduced...
>
> This was introduced by:
> 2006-11-01 Pete Steinmetz <[EMAIL PROTECTED]>
> Peter Bergner <[EMAIL PROTECTED]>
>
> * doc/invoke.texi: Add cpu_type power6x
>
> The function which we are crashing in is adjacent_mem_locations which is
> new with the above patch.
The parallel that is causing the ICE is a store with update RTL insn.
It seems like we should detect that and reach into the parallel and
grab the actual store insn. I'll look into adding that.
Peter
Breakpoint 5, adjacent_mem_locations (insn1=0x4040bf60,
insn2=0x4040bde0)
at /home/bergner/gcc/power6/gcc-mainline-power6/gcc/config/rs6000/rs6000.c:16955
16955 rtx a = SET_DEST (PATTERN (insn1));
(gdb) call debug_rtx (insn1)
(insn:HI 126 125 116
10 /home/bergner/gcc/power6/gcc-mainline-power6/gcc/libgcov.c:789
(parallel [
(set (mem:SI (plus:SI (reg/f:SI 1 1)
(reg:SI 182)) [0 S4 A32])
(reg:SI 181))
(set (reg/f:SI 1 1)
(plus:SI (reg/f:SI 1 1)
(reg:SI 182)))
]) 375 {movsi_update} (nil)
(nil))
(gdb) call debug_rtx (insn2)
(insn:HI 116 126 128
10 /home/bergner/gcc/power6/gcc-mainline-power6/gcc/libgcov.c:785 (set
(mem/s:SI (plus:SI (reg/f:SI 113 sfp)(const_int 12
[0xc])) [3 .overflow_arg_area+0 S4 A32])
(reg/f:SI 148 [ ap_I__overflow_arg_areaap_I_I_lsm.82 ])) 323
{*movsi_internal1} (nil)
(nil))
Re: bootstrap on powerpc fails
David Edelsohn wrote: Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. Me too. I'm a big proponent of testing, but I do think there should be some bang/buck tradeoff. (For example, we have tests in the GCC testsuite that take several minutes to run -- but never fail. I doubt these tests are actually buying us a factor of several hundred more quality quanta over the average test.) Machine time is cheap, but human time is not, and I know that for me the testsuite-latency time is a factor in how many patches I can write, because I'm not great at keeping track of multiple patches at once. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: bootstrap on powerpc fails
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote: Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. Any reason other than the obvious "I don't want bootstrap time to increase"? -eric
Re: bootstrap on powerpc fails
On Nov 7, 2006, at 4:40 PM, David Edelsohn wrote: Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. Any reason other than the obvious "bootstrap already takes too long"? Andrew's suggestion seemed reasonable too. -eric
Re: bootstrap on powerpc fails
> Kaveh R GHAZI writes: Kaveh> I tried many years ago and Mark objected: Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Kaveh> Perhaps we could take a second look at this decision? The average system Kaveh> has increased in speed many times since then. (Although sometimes I feel Kaveh> like bootstrapping time has increased at an even greater pace than chip Kaveh> improvements over the years. :-) I object. David
Re: bootstrap on powerpc fails
On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote: Perhaps we could take a second look at this decision? The average system has increased in speed many times since then. (Although sometimes I feel like bootstrapping time has increased at an even greater pace than chip improvements over the years. :-) Odd. You must not build java. I'd rather have one person that tests it occasionally and save the CPU cycles of all the rest of the folks, more scalable.
Re: bootstrap on powerpc fails
> > On Tue, 7 Nov 2006, Eric Botcazou wrote: > > > > But note this is with RTL checking enabled (--enable-checking=rtl). > > > > Can anyone refresh my memory: why is RTL checking disabled on the mainline? > > Eric Botcazou > > I tried many years ago and Mark objected: > http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html > > Perhaps we could take a second look at this decision? The average system > has increased in speed many times since then. (Although sometimes I feel > like bootstrapping time has increased at an even greater pace than chip > improvements over the years. :-) The other thing we could do is enable it only for stage1 (bootstrap's stage1) by default, just like we do for normal checking[1]. Thanks, Andrew Pinski [1] well that was broken with toplevel bootstrap, see the patch at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01231.html for the fix. We could extend this for RTL checking also.
Re: bootstrap on powerpc fails
On Tue, 7 Nov 2006, Eric Botcazou wrote: > > But note this is with RTL checking enabled (--enable-checking=rtl). > > Can anyone refresh my memory: why is RTL checking disabled on the mainline? > Eric Botcazou I tried many years ago and Mark objected: http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html Perhaps we could take a second look at this decision? The average system has increased in speed many times since then. (Although sometimes I feel like bootstrapping time has increased at an even greater pace than chip improvements over the years. :-) --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: bootstrap on powerpc fails
On Tue, Nov 07, 2006 at 11:40:01PM +0100, Eric Botcazou wrote: > > But note this is with RTL checking enabled (--enable-checking=rtl). > > Can anyone refresh my memory: why is RTL checking disabled on the mainline? Because it takes a LONG time. Janis
Re: bootstrap on powerpc fails
> But note this is with RTL checking enabled (--enable-checking=rtl). Can anyone refresh my memory: why is RTL checking disabled on the mainline? -- Eric Botcazou
Re: bootstrap on powerpc fails
> > Bootstrap off the trunk on powerpc-linux fails currently with: > > /cvs/gcc-svn/trunk/gcc/libgcov.c: In function =E2=80=98__gcov_execl=E2=80= > =99: > /cvs/gcc-svn/trunk/gcc/libgcov.c:796: internal compiler error: RTL check: e= > xpected code 'set' or 'clobber', have 'parallel' in adjacent_mem_locations,= > at config/rs6000/rs6000.c:16955 > > Is this already known or should I file a bugreport? I haven't tested > for over a week, so do not know when this was introduced... This was introduced by: 2006-11-01 Pete Steinmetz <[EMAIL PROTECTED]> Peter Bergner <[EMAIL PROTECTED]> * doc/invoke.texi: Add cpu_type power6x The function which we are crashing in is adjacent_mem_locations which is new with the above patch. But note this is with RTL checking enabled (--enable-checking=rtl). Andreas, next time can you report the options you pass to configure as a simple bootstrap just passed for me without any extra flags. Thanks, Andrew Pinski
