public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Reload patch to improve 386 code
@ 1997-08-21 16:51 Joern Rennecke
  0 siblings, 0 replies; 33+ messages in thread
From: Joern Rennecke @ 1997-08-21 16:51 UTC (permalink / raw)
  To: egcs

> > The problem with this is that you might have additional spills if you
> > remove reload inherits - when you inherit a reload that needs a secondary
> > reload, you extend the lifetime of only one reload register, instead of needing
> > two (or more, when a tertiary reload would be needed too.)
> 
> Are you sure? The inheritance code in choose_reload_regs is run after all
> spilling has been done, so I don't think removing it could cause additional
> spills.


You are right, I mixed up something here.  What I actually saw was when
an inherit was missed, the new reload - or its secondary reloads -
would clobber other reload registers, which could otherwise have been used
for subsequent inherits.
reload_cse coudn't clean up the mess - it just changed the reload for the
missed inherit from a memory-register to a register-register move.
It isn't clever enough to reassign reload registers and then reclaim the
freed register for further cse.

> The reason I'm not happy with the inheritance code is that find_equiv_reg
> is overly conservative; e.g. it misses cases like this:
> 
> movl %eax,16(%esp)
> movl %eax,some_symbol
> addl 16(%esp),%ebx
> 
> where the addl could inherit the value in %eax. My idea is to teach

I think my inheritance patches would fix that too.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Problems on PowerPC...
@ 1997-08-21 16:51 David Edelsohn
  1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
  0 siblings, 1 reply; 33+ messages in thread
From: David Edelsohn @ 1997-08-21 16:51 UTC (permalink / raw)
  To: egcs

>>>>> David McWherter writes:

David> I dunno if they're C++ constructors, but a function pointer from
David> __CTOR_LIST__ is being picked off and run by __do_global_ctors_aux() when
David> I compile with egcs.  When I compile genattr with my standard gcc, it
David> doesn't do so.  The egcs-compiled genattr dies because the pointer it
David> picks out from __CTOR_LIST__ is a pointer to a block of illegal
David> instructions, and a SIGILL is generated.
 
David> I dunno.  My standard-gcc-built code seems to have empty __CTOR_LIST__'s,
David> but the egcs stuff has something there.

	All of the various Linux for PowerPC use SVR4 which has init and
fini object file sections.  Something is ending up in the __CTOR_LIST__
when using egcs that should not be present (genattr and obstack.o are pure
C, not C++: no constructors exist).  I would assume that something in the
rs6000/sysv4.h configuration distributed in the pax files on linuxppc.org
has not made it back to the FSF sources on which egcs is based.

David

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: egcs repository
@ 1997-08-21 15:20 Joel Sherrill
  1997-08-21 15:47 ` Reload patch to improve 386 code Bernd Schmidt
  0 siblings, 1 reply; 33+ messages in thread
From: Joel Sherrill @ 1997-08-21 15:20 UTC (permalink / raw)
  To: egcs

On 20 Aug 1997, Jason Merrill wrote:

> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
> >   In message <199708192228.PAA28350@yorick.cygnus.com>you write:
> >> Seems to me that egcs should be one more directory down, so we can add
> >> libstdc++ et al to the toplevel directory (and eventually move libF77
> >> there, too).
> 
> > I've got no problems with that...
> 
> > Or maybe make gcc a subdir of egcs.  Who knows...
> 
> I don't feel strongly either way.  Does anyone else?  I'm figuring we can
> just use the Cygnus toplevel directory stuff as seen in gdb et al.

If this is what is referred to as the "one-tree" build in the crossgcc
world, then I am personally all for it.  This is a big step in the right
direction to address gcc support library and include file build
order problems.

--joel

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-19 19:00 Joern Rennecke
  0 siblings, 0 replies; 33+ messages in thread
From: Joern Rennecke @ 1997-08-19 19:00 UTC (permalink / raw)
  To: egcs

> Then, there are some simplifications that could be done. I don't like the
> inheritance code, find_equiv_reg and all that. IMHO reload shouldn't try to be
> very clever about this sort of thing - the reload_cse_regs pass can be made
> more clever. I've already submitted a patch to Kenner that enables
> reload_cse_regs to generate optional reloads. If we could add some more
> cleverness (e.g. deleting redundant stores into spill slots or eliminating
> register-register copies), quite a bit of code in reload could be deleted.
> I've already made some experiments in this direction which indicate that this
> approach may be feasible.

The problem with this is that you might have additional spills if you
remove reload inherits - when you inherit a reload that needs a secondary
reload, you extend the lifetime of only one reload register, instead of needing
two (or more, when a tertiary reload would be needed too.)

Moreover, if you remove reload inherits from / to memory, you might end
up with code that looks like it could have an alias problem for doing cse on
it, and reload_cse can't do anything.

I actually think that the reload inheriting code should be mae smarter.
I did some patches to do that and got more benefit for the code I tested
than from reload_cse.  However, they never got accepted for the FSF gcc...
I'll re-fit them into egcs when I find some time for that.  Should I
sent them as multiple (conflicting) patches or as a single patch?

The main issues are:

- inheriting reloads from non-reload registers

- emitting more complete REG_ notes when doing reloads, so that they can
  be found for inherits

- being smarter about finding possible inherits

> Another way of simplifying reload would be to try to generate auto-inc
> addressing after reload has run, not before. That would eliminate some more
> special-case code (and it might make other parts of the compiler simpler as
> well).

But then you wouldn't get the heuristics for the earlier passes right.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-19  8:50 Jakub Jelinek
  0 siblings, 0 replies; 33+ messages in thread
From: Jakub Jelinek @ 1997-08-19  8:50 UTC (permalink / raw)
  To: egcs

> 
>    Date: Mon, 18 Aug 1997 11:17:38 -0400 (EDT)
>    From: meissner@cygnus.com
> 
>    I think it is an horrible kludge that reload is run as a pass after
>    global-alloc, and that it forces reload registers not to be used
>    for any other purpose (which is murder on the x86 with each
>    register being special purpose in some way).
> 
> Before this leaves my head, I wanted to point something out which
> you've reminded me of.  When the scheduler (this applies to both the
> original and Haifa versions equally) becomes aggressive, it produces a
> large number of reloads in certain situations.  Reloads which would
> not have happened if scheduling did not take place.  This happens
> especially if register pressure is high already.  I noticed this
> particularly on RISC platforms, seems in this case the more registers
> available the worse things became when the register usage was
> saturated.

I thought about a quick solution, which would be during global-alloc, if it
finds out that the number of hard registers is exceeded, it could try to
undo some short pseudo setup RTL sequence merges and move them to the place
of the actual use, if the pseudo being set up is a constant and computable
in small number of instructions not involving memory loads.
Like that, we could rid of the following horror on sparc64:

	sethi %hi(var1), %r1
	stx %r1, [%sp + NN]
	...
	ldx [%sp + NN], %r1
	or %r1, %lo(var1), %r1
	stx %r1, [%sp + NN]
	...
some loop:
	...
	ldx [%sp + NN], %r1
	ldx [%r1], %r1
	...

and could have:

some loop:
	...
	sethi %hi(var1), %r1
	ldx [%r1 + %lo(var1)], %r1
	...

instead...

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take fool power from the UltraSparc
Linux version 2.0.30 on a sparc machine (291.64 BogoMips).
___________________________________________________________________

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: egcs: A new compiler project to merge the existing GCC forks (fwd)
@ 1997-08-19  7:36 Robert Wilhelm
  1997-08-19  8:08 ` Reload patch to improve 386 code Bernd Schmidt
                   ` (2 more replies)
  0 siblings, 3 replies; 33+ messages in thread
From: Robert Wilhelm @ 1997-08-19  7:36 UTC (permalink / raw)
  To: egcs

> 
> Can someone point me the location of mdbench?
>

http://www.sissa.it/furio/Mdbnch/info.html

Robert

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Reload patch to improve 386 code
@ 1997-08-18 20:47 Mike Meissner
  0 siblings, 0 replies; 33+ messages in thread
From: Mike Meissner @ 1997-08-18 20:47 UTC (permalink / raw)
  To: egcs

Bernd, I just checked at the FSF, and did not notice a copyright
assignment from you.  Could you do that so that we can consider using
your code?  If are employed as a programmer, particularly if you
developed the patch on company time, you need to get somebody who can
sign for the company (such as a vice president or director) to
disclaim all copyright claims to the code.  Here is the sample from
the COPYING file, you would obviously alter the names.

  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  `Gnomovision' (which makes passes at compilers) written by James Hacker.

  <signature of Ty Coon>, 1 April 1989
  Ty Coon, President of Vice

You would then write a similar copyright disclaimer, giving the
changes to the FSF.

-- 
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 20:46 Joern Rennecke
  0 siblings, 0 replies; 33+ messages in thread
From: Joern Rennecke @ 1997-08-18 20:46 UTC (permalink / raw)
  To: egcs

> 
>   In message <199708181855.OAA03711@jenolan.rutgers.edu>you write:
>   > Before this leaves my head, I wanted to point something out which
>   > you've reminded me of.  When the scheduler (this applies to both the
>   > original and Haifa versions equally) becomes aggressive, it produces a
>   > large number of reloads in certain situations.  Reloads which would
>   > not have happened if scheduling did not take place.  This happens
>   > especially if register pressure is high already.  I noticed this
>   > particularly on RISC platforms, seems in this case the more registers
>   > available the worse things became when the register usage was
>   > saturated.
> Yup.  Absolutely.  This is a known issue with schedulers in general;
> you can see this in action if you look at fpppp in spec.
> 
> The haifa scheduler has some code to "prefer" schedules which don't
> lengthen register lifetimes, but I don't know how effective it really
> is.  The normal scheduler has some code to do this too, but it's less
> effective than haifa.
> 
> However, I've done experiments and the more I make the scheduler
> try to reduce register lifetimes, the worse _overall_ performance I
> see.
> 
> It almost makes me think such code should be dependent on the number
> of registers actually in the code -- ie once the ratio of pseudos
> to hard registers hits some magic point, the code to shorten lifetimes
> kicks in and tries to keep the scheduler from extending register
> lifetimes.

I think we could get better results if the scheduler just does its work,
but leaves enough information for reload so that reload can do un-do some
aggressive scheduling if this saves some reloads and these savings
outweigh the penalty for sub-optimal scheduling.

In a similar vein, it would be useful if regmove could pass some information
of the transformation it has done down to reload.  If some value ends up in
a stack slot, some of the regmove transformation would better be undone.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 18:55 David S. Miller
  1997-08-18 19:09 ` Jeffrey A Law
  0 siblings, 1 reply; 33+ messages in thread
From: David S. Miller @ 1997-08-18 18:55 UTC (permalink / raw)
  To: egcs

   Date: Mon, 18 Aug 1997 11:17:38 -0400 (EDT)
   From: meissner@cygnus.com

   I think it is an horrible kludge that reload is run as a pass after
   global-alloc, and that it forces reload registers not to be used
   for any other purpose (which is murder on the x86 with each
   register being special purpose in some way).

Before this leaves my head, I wanted to point something out which
you've reminded me of.  When the scheduler (this applies to both the
original and Haifa versions equally) becomes aggressive, it produces a
large number of reloads in certain situations.  Reloads which would
not have happened if scheduling did not take place.  This happens
especially if register pressure is high already.  I noticed this
particularly on RISC platforms, seems in this case the more registers
available the worse things became when the register usage was
saturated.

Another thing I saw gcc do for a register constrained function was the
following.  Consider a function which references a lot of global data
structures, which it iterates over as a 3 level indirected table.  It
also references 2 or 3 global pieces of data in a few distinct places
within the iteration (the specific example is specifically the
function mm/memory.c:copy_page_range() on sparc64 in the Linux kernel)
A rough outline is:

inline copy_one_pte() {
	if(pte_none(pte))
		return;
	if(!pte_present(pte)) {
		duplicate_swap_information();
		return;
	}
	copy_pte_info_and_maybe_cow();
}

inline copy_pte_range() {
	for_all_ptes_in_this_pmd()
		copy_one_pte();
}

inline copy_pmd_range() {
	for_all_pmds_in_this_pgd()
		copy_pte_range();
}

copy_page_range() {
	for_all_pgds_in_this_range()
		copy_pmd_range();
}

Now, I have two global physical addresses I use for "null" page
tables, which is what newly allocated page tables point to before they
are set to point to anything specific.  There is heavy inlining done
here and on sparc64 it can end up allocating 300 or 400 bytes of stack
space.  Anyways, back to my main point, the two physical addresses for
the null page table pages live in two global variables
"null_pte_table" and "null_pmd_table".  The progression in the
produced code wrt. these two variables is:

copy_page_range:

	sethi	%hi(null_pte_table), %r
	or	%r, %lo(null_pte_table), %r
	stx	%r, [%sp + slot1]
	sethi	%hi(null_pmd_table), %r
	or	%r, %lo(null_pmd_table), %r
	stx	%r, [%sp + slot2]

...

main_loop:
	...
	/* we need to use null_pmd_table's value here */
	ldx	[%sp + slot1], %r
	ldx	[%r], %r2
	use it
	stx	%r2, [%sp + slot3]
	...
	/* we need to use null_pte_table's value here */
	ldx	[%sp + slot2], %r
	ldx	[%r], %r2
	use it
	stx	%r2, [%sp + %slot4]	
	...
	/* need again to use null_pmd_table's value */
	ldx	[%sp + slot3], %r
	use it
	...
	/* need again to use null_pte_table's value */
	ldx	[%sp + slot4], %r
	use it
	...
	b	main_loop

Anyways you get the picture, I see often these "gradual" reloads,
where final values are computed partially, given a stack slot for
reloading purposes, and then loaded back and computed further, then
given yet another stack slot.  On RISC systems this can account for a
significant portion of the stack slots taken up for a given function.

   Now, given it is a rather critical piece of the compiler, it may
   take months if not years to get it better than it currently is.

Well, perhaps it would be prudent to have people start now in the
background to get this work going?

Later,
David "Sparc" Miller
davem@caip.rutgers.edu

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 15:36 Toon Moene
  0 siblings, 0 replies; 33+ messages in thread
From: Toon Moene @ 1997-08-18 15:36 UTC (permalink / raw)
  To: egcs

  In message <9708181258.AA19853@moene.indiv.nluug.nl> I wrote:

  > Isn't this something that would have been solved [ coniunctivus  
  > irrealis ! ] by live range splitting ?

Jeff:

>  Not entirely.  live range splitting should significantly
>  reduce the number of spills, but it won't always be able
>  to completely eliminate them (in theory it can completely
>  eliminate them, but in practice it doesn't).  Thus you
>  still need to deal with spilling registers.

I tried to reply to the following:

[ Bernd Schmidt: ]

>  it is
>  possible to use register life information to determine
>  that certain pseudos are not live across any instructions
>  that need reloads, and thus need not be spilled.

i.e. the _effect_ that live range splitting has on spilling; I know  
it cannot eliminate it.

Cheers,
Toon.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 15:11 meissner
  0 siblings, 0 replies; 33+ messages in thread
From: meissner @ 1997-08-18 15:11 UTC (permalink / raw)
  To: egcs

|   In message <9708181258.AA19853@moene.indiv.nluug.nl>you write:
|   > Isn't this something that would have been solved [ coniunctivus  
|   > irrealis ! ] by live range splitting ?
| Not entirely.  live range splitting should significantly reduce
| the number of spills, but it won't always be able to completely
| eliminate them (in theory it can completely eliminate them, but
| in practice it doesn't).  Thus you still need to deal with spilling
| registers.

Yes, I think it is obvious that you will always need to spill registers.  Also,
live range splitting as I'm currently implementing it will still be generating
spills.  I do think the previous posting on register spills is also helpful and
plan to look at it when I get in the office (I didn't mention to disparage it,
my first posting was made pre-coffee).  My comment on reload is meant for more
reload as we currently know it.  I think it is an horrible kludge that reload
is run as a pass after global-alloc, and that it forces reload registers not to
be used for any other purpose (which is murder on the x86 with each register
being special purpose in some way).  I think it should be integrated into
global-alloc, taking lifetimes, ranges, etc. into consideration, possibly
leaving the fossil reload for when you are not optimizing.  Given that reload
has pretty much been the place where we all fear to tread, at least since RMS
handed over the gcc2 reigns to Kenner (and even in the 1.3x time frame, I got
the sense that RMS no longer had a good handle on reload anymore), I think it
is time for a rethought.  Now, given it is a rather critical piece of the
compiler, it may take months if not years to get it better than it currently
is.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 14:53 Toon Moene
  0 siblings, 0 replies; 33+ messages in thread
From: Toon Moene @ 1997-08-18 14:53 UTC (permalink / raw)
  To: egcs

>  I have come up with a patch for the reload pass that can
>  improve the generated code on the i386 quite dramatically.
>  The problem with reload is that when it decides to spill
>  a hard register, it spills _all_ pseudos allocated to
>  this hard register.  This is often not necessary, it is
>  possible to use register life information to determine
>  that certain pseudos are not live across any instructions
>  that need reloads, and thus need not be spilled.

Isn't this something that would have been solved [ coniunctivus  
irrealis ! ] by live range splitting ?

"pseudo's that are not live across instructions" sounds to me as  
the definition of the place to split the liveness range.

Or am I missing something ?

OTOH, "beter een vogel in de hand dan tien in de lucht" (sorry,  
couldn't resist).

Cheers,
Toon.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Monday morning
@ 1997-08-18 14:53 Philippe Laliberte
  1997-08-18 14:54 ` Reload patch to improve 386 code Jeffrey A Law
  0 siblings, 1 reply; 33+ messages in thread
From: Philippe Laliberte @ 1997-08-18 14:53 UTC (permalink / raw)
  To: egcs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Hello,

        I have been reading the list and looking at the snapshot over the
weekend, and it seem's clear that I'm a bit lost. Can some one point to me some
reading to do in the hope that I can contribute one day something usefull?

        Utill that day I'll keep reading and trying to play with the snapshot.
Thank's for being their.


---

Bonne journée,
Have a nice day,

  _____________________________________________________________________
|Philippe Laliberte             |        http://www.mlink.net/~arsphl/  |
| ___ Arsphl ___                |        http://oeil.qc.ca/             |
| arsphl@mlink.net              |                                       |
| arsphl@oeil.qc.ca             |        NO SPAM PLEASE                 |
  _____________________________________________________________________

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Reload patch to improve 386 code
@ 1997-08-18 14:53 meissner
  0 siblings, 0 replies; 33+ messages in thread
From: meissner @ 1997-08-18 14:53 UTC (permalink / raw)
  To: egcs

| >  I have come up with a patch for the reload pass that can
| >  improve the generated code on the i386 quite dramatically.
| >  The problem with reload is that when it decides to spill
| >  a hard register, it spills _all_ pseudos allocated to
| >  this hard register.  This is often not necessary, it is
| >  possible to use register life information to determine
| >  that certain pseudos are not live across any instructions
| >  that need reloads, and thus need not be spilled.
| 
| Isn't this something that would have been solved [ coniunctivus  
| irrealis ! ] by live range splitting ?
| 
| "pseudo's that are not live across instructions" sounds to me as  
| the definition of the place to split the liveness range.
| 
| Or am I missing something ?

My opinion is reload needs to be rewritten completely.  I'm in the middle of
working on a beginning of live range splitting right now, but it probably will
be some time before it moves to egcs (ie, its not ready yet).

| OTOH, "beter een vogel in de hand dan tien in de lucht" (sorry,  
| couldn't resist).
| 
| Cheers,
| Toon.
| 

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: Test result for 970814 on native sparc-sun-solaris2.5.1
@ 1997-08-18  8:13 Klaus Kaempf
  1997-08-18  8:22 ` Reload patch to improve 386 code Bernd Schmidt
  1997-08-18 10:11 ` Bernd Schmidt
  0 siblings, 2 replies; 33+ messages in thread
From: Klaus Kaempf @ 1997-08-18  8:13 UTC (permalink / raw)
  To: egcs

> 
> Normally, I don't think we should pollute up a list like this one with
> testresults, but since we have a first snapshot, I thought I would do
> one:

Maybe we shouldn't pollute the list with testresults but how about 'polluting'
a web site (WWW-Gnat comes in mind) with such results and open bugs. Adding a
'responsible' or 'working on' list will help getting the right people to work
on the bugs.

Klaus
-- 
proGIS Software                 E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K"ampf      Fax:    0241-47067-29
Jakobstr. 117                   Voice:  0241-47067-11
D-52064 Aachen                  WWW:	http://www.progis.de

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~1998-09-07 19:09 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <Pine.SOL.3.90.970819095143.291G-100000@starsky.informatik.rwth-aachen.de>
1998-09-04  5:03 ` Reload patch to improve 386 code Jeffrey A Law
1998-09-04  5:05   ` Bernd Schmidt
1998-09-04 22:36     ` Joern Rennecke
1998-09-05  4:45     ` Jeffrey A Law
1998-09-05 15:49       ` Joern Rennecke
1998-09-05 15:44         ` Jeffrey A Law
1998-09-06  1:09           ` Mark Mitchell
1998-09-06  1:09             ` Jeffrey A Law
1998-09-07  9:48       ` Bernd Schmidt
1998-09-07 19:09         ` Jeffrey A Law
1998-09-07 19:09         ` Joern Rennecke
1998-09-07 18:26           ` Jeffrey A Law
1998-09-04 21:38   ` Joern Rennecke
1998-09-04 21:38     ` Jeffrey A Law
1997-08-21 16:51 Joern Rennecke
  -- strict thread matches above, loose matches on Subject: below --
1997-08-21 16:51 Problems on PowerPC David Edelsohn
1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-21 15:20 egcs repository Joel Sherrill
1997-08-21 15:47 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-19 19:00 Joern Rennecke
1997-08-19  8:50 Jakub Jelinek
1997-08-19  7:36 egcs: A new compiler project to merge the existing GCC forks (fwd) Robert Wilhelm
1997-08-19  8:08 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-19  8:08 ` Bernd Schmidt
1997-08-19  8:08 ` Jeffrey A Law
1997-08-18 20:47 Mike Meissner
1997-08-18 20:46 Joern Rennecke
1997-08-18 18:55 David S. Miller
1997-08-18 19:09 ` Jeffrey A Law
1997-08-18 15:36 Toon Moene
1997-08-18 15:11 meissner
1997-08-18 14:53 Toon Moene
1997-08-18 14:53 Monday morning Philippe Laliberte
1997-08-18 14:54 ` Reload patch to improve 386 code Jeffrey A Law
1997-08-18 14:53 meissner
1997-08-18  8:13 Test result for 970814 on native sparc-sun-solaris2.5.1 Klaus Kaempf
1997-08-18  8:22 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-18 10:11 ` Bernd Schmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).