Re: egcs release

Re: egcs release

[Jim Wilson]

	Wed Jul 30 14:43:34 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle access stack memory
		beyond the stack pointer via the frame pointer.
		(STACK_POINTER_REG_NREGS): New. Default as 1.

We already have a patch installed that fixes this, and which works for
both the old (sched.c) and new (haifa-sched.c) schedulers.  Patches that
only fix sched.c aren't very userful anymore.

	Sun Jul 13 13:39:15 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

		* sched.c (sched_analyze_2): Handle USE_PIC_OFFSET_TABLE_REG if
		defined.
		(PIC_OFFSET_TABLE_REG_NREGS): New. Default as 1.

		* config/i386/i386.h (USE_PIC_OFFSET_TABLE_REG): New. True if
		the PIC base register is used.

I suggest we use this patch.  This fixes the testcase that you wrote your
patch for, and works for both schedulers.

Wed Aug 27 14:52:54 1997  Jim Wilson  <wilson@cygnus.com>

	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.

Index: i386.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.1.1.1
diff -p -r1.1.1.1 i386.c
*** i386.c	1997/08/11 15:57:16	1.1.1.1
--- i386.c	1997/08/27 21:52:31
*************** ix86_expand_epilogue ()
*** 2128,2133 ****
--- 2128,2143 ----
  
    xops[2] = stack_pointer_rtx;
  
+   /* When -fpic, we must emit a scheduling barrier, so that the instruction
+      that restores %ebx (which is PIC_OFFSET_TABLE_REGNUM), does not get
+      moved before any instruction which implicitly uses the got.  This
+      includes any instruction which uses a SYMBOL_REF or a LABEL_REF.
+ 
+      Alternatively, this could be fixed by making the dependence on the
+      PIC_OFFSET_TABLE_REGNUM explicit in the RTL.  */
+   if (flag_pic)
+     emit_insn (gen_blockage ());
+ 
    if (nregs > 1 || ! frame_pointer_needed)
      {
        if (frame_pointer_needed)

Re: egcs-2.90.02 970825, hppa1.1-hp-hpux9.01 bootstraps okay

[Jeffrey A Law]

  In message <199708272133.RAA18344@caip.rutgers.edu>you write:
  > 	I bootstrapped egcs-2.90.02 970825 on hppa1.1-hp-hpux9.01 using
  > BOOTCFLAGS='-O3 -funroll-all-loops' and cc for stage1 with native as/ld. 
  > I got a clean "make compare" and identical c-torture results with those
  > of gcc2-970721.  (Later gcc2 snapshots don't bootstrap for me.)
Good/bad.

Good that we generate idential c-torture results, bad because
later gcc2 snapshots don't bootstrap.

Odds are this is a reload issue that I tried to explain to
Kenner without much success.  I'm going to have to take another
stab at it within the next couple days.

[ egcs has code to avoid the reload problem... ]

jeff

Re: Here are the g++ test results

[Jeffrey A Law]

  In message <Pine.PMDF.3.91.970827170134.538982528A-100000@MPS.OHIO-STATE.EDU>
you write:
  > > I believe it is a bug in the testsuite, but I need to see the contents
  > > of the $objdir/libio to make sure.
  > > 
  > Here are the contents of $objdir/libio, sorry about the delay.
THanks.  Looks like the message got garbled somewhere.

Regardless, I think I know what the problem is.  Try this patch
to dejagnu:

Index: lib/libgloss.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/lib/libgloss.exp,v
retrieving revision 1.48
retrieving revision 1.49
diff -c -r1.48 -r1.49
*** libgloss.exp	1997/08/06 04:42:09	1.48
--- libgloss.exp	1997/08/07 01:42:15	1.49
***************
*** 166,172 ****
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/libio.a];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]
--- 166,172 ----
  	set gccpath [file dirname [file dirname ${base_dir}]]
      }
  
!     set libio_bin_dir [lookfor_file ${gccpath} libio/_G_config.h];
      set libio_src_dir [lookfor_file ${srcdir} libio/Makefile.in]
      if { $libio_bin_dir != "" && $libio_src_dir != "" } {
  	set libio_src_dir [file dirname ${libio_src_dir}]

Re: Performance; was: 68k problem.

[Jeffrey A Law]

  In message <9708272100.AA01051@moene.indiv.nluug.nl>you write:
  > i.e. not as bad as I thought [38000+ seconds], but certainly worse  
  > than the g77-0.5.21-970811 + gcc-2.7.2.2 result (~ 10 %).
Just a note; I've got -freduce-all-givs and -fmove-all-movables
in my source tree, and barring any natual disasters they should
get checked in and appear in the next snapshot (tonight/tomorrow).

I'm not including -frerun-loop yet; I want to think about it a
little -- my experiences with trying to rerun passes hasn't been
good.  At various times over the years I've done this with cse
and flow, and in both cases doing so has destabilized things
pretty badly.

Jeff

Re: egcs release

[H.J. Lu]

> I have lots of bug reports and patches from you.  It would be helpful if
> you could prioritize them, so I know which ones to work on first.
> 

Thanks. I'd like to see my libio/libstdc++ patches get installed
first.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: egcs release

[Jim Wilson]

	Thanks. I can use egcs compile glibc now. It passed "make check".
	BTW, how about the long long bug in cpp? I have a patch for it.

I have lots of bug reports and patches from you.  It would be helpful if
you could prioritize them, so I know which ones to work on first.

Jim

Re: egcs release

[H.J. Lu]

> I suggest we use this patch.  This fixes the testcase that you wrote your
> patch for, and works for both schedulers.
> 
> Wed Aug 27 14:52:54 1997  Jim Wilson  <wilson@cygnus.com>
> 
> 	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.
> 

Thanks. I can use egcs compile glibc now. It passed "make check".
BTW, how about the long long bug in cpp? I have a patch for it.


H.J.

Re: egcs release

[Jeffrey A Law]

  In message <199708270601.XAA07324@cygnus.com>you write:
  > 	You didn't include any actual patch...
  > 
  > I have the patches.  Both were previously submitted to the gcc2 developers.
OK.

  > 
  >   > 	* sched.c (sched_analyze_2): Handle access stack memory
  >   > 	beyond the stack pointer via the frame pointer.
  >   > 	(STACK_POINTER_REG_NREGS): New. Default as 1.
  > 
  > There is incidentally already a fix for this in the gcc2 sources.
OK.  I don't see that there's any particular benefit in doing anything
different for this in egcs, so I'll extract the patch from the gcc2
tree and put it in egcs.

  > Both H.J. Lu's patch and the already installed gcc2 patch have advantages
  > and disadvantages.  I am kind of leaning towards the gcc2 one (or the sched
  > barrier after the prologue), as it does a much better job of avoiding
  > unnecessary instructions dependencies, and hence will hurt performance less> .
Agreed.  My vote is the gcc2 solution.

  > This patch is similar in spirit to the first.  It makes every instruction
  > using a SYMBOL_REF depend on any instruction which sets the
  > PIC_OFFSET_TABLE_REGNUM.  This is because, when pic, instructions using
  > a SYMBOL_REF implicitly depend on this register.
Eee-yuk.

Well, I'm going to sound like Kenner, but when you lie to the compiler,
bad things happen.

Short term, I think a barrier would be fine or showing the use of
the pic register in RTL (the barrier is obviously a quicker solution).

Long term I think we really need to rethink how PIC works; the current
scheme does lead to "little white lies" that bite us regularly.

It also tends to pessimize loops which make PIC references.  Loop
does nothing when it finds a loop with a hard register that is
referenced, but never set -- as is the case with the PIC register.

Fixing this for static store data access on the PA (which is pic-like)
was the single biggest performance improvement I've made in the five
years I've been working on the PA port.

[ The difference on the PA is the dp/gp register is set in crt0
  and effectively read-only throughout the life of the program,
  thus showing it in loads/stores really provides no useful
  information to the compiler.  True PIC references on the PA
  actually show the pic register (which is different from dp/gp). ]

Jeff

Re: egcs release

[Jim Wilson]

	You didn't include any actual patch...

I have the patches.  Both were previously submitted to the gcc2 developers.

  > 	* sched.c (sched_analyze_2): Handle access stack memory
  > 	beyond the stack pointer via the frame pointer.
  > 	(STACK_POINTER_REG_NREGS): New. Default as 1.

There is incidentally already a fix for this in the gcc2 sources.
The fix in gcc2 solves this problem by adding a set of FP in the instruction
that sets the SP, thus any instruction using fp then becomes dependent on
the instruction that sets the SP.  This has roughly the same affect as adding
a scheduling barrier, but allows a little more scheduling freedom, and is
perhaps a little less safe.

Both H.J. Lu's patch and the already installed gcc2 patch have advantages
and disadvantages.  I am kind of leaning towards the gcc2 one (or the sched
barrier after the prologue), as it does a much better job of avoiding
unnecessary instructions dependencies, and hence will hurt performance less.

	I'd have to see the patch to be able to comment on this.

This patch is similar in spirit to the first.  It makes every instruction
using a SYMBOL_REF depend on any instruction which sets the
PIC_OFFSET_TABLE_REGNUM.  This is because, when pic, instructions using
a SYMBOL_REF implicitly depend on this register.

The general consensus when this first came up is that the x86 back end should
emit RTL that explicitly uses PIC_OFFSET_TABLE_REGNUM in the RTL, so that the
dependence is obvious to all gcc optimization passes.  No one tried to
implement this though, and it isn't clear if this is practical.

I suspect what really needs to be done here is put some kind of scheduling
barrier before the epilogue.  It is an epilogue insn moved towards the front
of the function that is causing the problem.  I still need to look at this
some more though.  I have only taken a superficial look so far.

Jim

Re: egcs release

[Jeffrey A Law]

You didn't include any actual patch...

  In message <m0x33vo-0004ecC@ocean.lucon.org>you write:
  > Wed Jul 30 14:43:34 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
  > 
  > 	* sched.c (sched_analyze_2): Handle access stack memory
  > 	beyond the stack pointer via the frame pointer.
  > 	(STACK_POINTER_REG_NREGS): New. Default as 1.
I would recommend against this.

The way to handle this is to emit a barrier before cutting back
the stack in the epilogue.  At least that's the way the vast
majority of targets handle this problem.



  > Sun Jul 13 13:39:15 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
  > 
  > 	* sched.c (sched_analyze_2): Handle USE_PIC_OFFSET_TABLE_REG if
  > 	defined.
  > 	(PIC_OFFSET_TABLE_REG_NREGS): New. Default as 1.
  > 
  > 	* config/i386/i386.h (USE_PIC_OFFSET_TABLE_REG): New. True if
  > 	the PIC base register is used.
I'd have to see the patch to be able to comment on this.

jeff

Re: egcs release

[H.J. Lu]

Hi,

The bugs fixed by the patches enclosed here should be fixed in
the first egcs release. Otherwise, even glibc may be miscompiled
on linux/x86.

BTW, my 970731-1/runit test triggers the second bug. The first
one is hard to write a generic test case for. You need to look
at the asm code to see the bug.

Thanks.


H.J.
---
Wed Jul 30 14:43:34 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* sched.c (sched_analyze_2): Handle access stack memory
	beyond the stack pointer via the frame pointer.
	(STACK_POINTER_REG_NREGS): New. Default as 1.

Sun Jul 13 13:39:15 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* sched.c (sched_analyze_2): Handle USE_PIC_OFFSET_TABLE_REG if
	defined.
	(PIC_OFFSET_TABLE_REG_NREGS): New. Default as 1.

	* config/i386/i386.h (USE_PIC_OFFSET_TABLE_REG): New. True if
	the PIC base register is used.