Re: egcs repository

Re: egcs repository

[Joel Sherrill]

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

Re: [EGCS] [REQ] If the x86 people could do something about this...

[Marc Lehmann]

John Beppu wrote:
>
>        The problem I have with gcc's code generation for i386+
>        regards the assigning of constants to variables in
>        memory.  This constructor just sets a lot of things to 0.
>        The assembly output of this constructor is a bit
>        disappointing, though.  
>

pgcc does address this in a better way, but the patches
are not in a form to be suitable for inclusion
into egcs currently..

>        I would love it if gcc would be so kind as to put $0

some people are already working on this problem.


      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> Specific questions/comments:
> 
> In move_insn, is there some reason why you can't call reemit_notes
> during the loop on SCHED_GROUP_P insns?
> 
> ie, does this work instead?  Seems cleaner than using another loop
> if it works.
> 
> {
>   rtx new_last = insn;
> 
>   while (SCHED_GROUP_P (insn))
>     {
>       rtx prev = PREV_INSN (insn);
>       move_insn1 (insn, last);
>       reemit_notes (insn, insn);
>       insn = prev;
>     }
> 
>   move_insn1 (insn, last);
>   return reemit_notes (new_last, new_last);
> }

I've thought about something like this, but this code won't work, I think.
It will call reemit_notes twice for the last insn in the SCHED_GROUP and
not at all for the first one. I've tried thinking of ways to use just one
loop, but they all had problems with putting all notes in the right places.

Bernd

Re: Reload patch to improve 386 code

[Bernd Schmidt]

> 
> 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.
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
reload_cse_regs about these cases, and if it can be made clever enough,
maybe (hopefully) the inheritance code in choose_reload_regs will become
redundant.

> 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'm aware of that. So far I have a patch that makes reload keep track of
all memory locations in the frame that it creates and teaches the alias
analysis that those can't conflict with any other memory references.  The
patch is very simple, only a couple of lines, and eliminates that part of
the problem completely from what I have seen. It also reduces dependencies
between insns, so it would be good to have something like this for the
benefit of the scheduler as well.

> > 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.

Which heuristics are those?

Bernd

Re: mdbench for g77 & f2c+gcc

[Oleg Krivosheev]

Hi,

On Thu, 21 Aug 1997, Oleg Krivosheev wrote:

> Date: Thu, 21 Aug 1997 00:56:37 -0500 (CDT)
> From: Oleg Krivosheev <kriol@FNAL.GOV>
> To: Arno PAHLER <paehler@atlas.rc.m-kagaku.co.jp>,
>     Christian Kuehnke
     <Christian.Kuehnke@arbi.Informatik.UNI-OLDENBURG.DE>,
>     "H.J. Lu" <hjl@lucon.org>
> Cc: egcs@cygnus.COM, furio@sissa.IT
> Subject: mdbench for g77 & f2c+gcc
> 
> 
> Hi, All
> 
> i've benchmarked g77 and f2c+gcc
> using mdbench on Ultrasparc II / 200Mhz
> and Pentium/133Mhz/256k cache.
> 
> g77 and gcc were build from egcs-ss-970814.tar.gz sources
> with Haifa scheduler plus
> Bernd Schmidt haifa patch plus
> Christian ultra patch plus
> Jim Wilson patch.
> 
> All numbers are averaged over five runs.
> ultra and P133 both had zero load.
> 
> 1. Ultra II/200 mhz
> 
> jor-el ~/work/Project/tmp$ fpversion
>  A SPARC-based CPU is available.
>  CPU's clock rate appears to be approximately 200.2 MHz.
>  Kernel says CPU's clock rate is 200.0 MHz.
>  Kernel says main memory's clock rate is 100.0 MHz.
> 
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
>  FPU's frequency appears to be approximately 201.5 MHz.
> 
>  Use "-xtarget=ultra -xcache=16/32/1:1024/64/1" code-generation option.
>  
> 
> g77 -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
> -fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
> mdbnch.f
> 
> 17.56 sec
> 
> not bad, huh!!! official data are
> 
> Sun Ultra 2 (200Mhz), Solaris 2.5.1, SC4.0 FORTRAN [^] ........ 15.7 s+
> 24Apr96
> 
> my own result with sun f77 4.2 is 16.5 sec
> 
> g77 is only ~10% slower !

i just tried to compile without scheduler intervention:

g77 -O6 -fno-schedule-insns -fno-schedule-insns2 -funroll-all-loops
-fomit-frame-pointer -ffast-math -fstrength-reduce -fthread-jumps
-mcpu=ultrasparc -mtune=ultrasparc mdbnch.f 

21.04 sec

Haifa gives quite substantial contribution into performance !

OK

Re: cross compiling to m68k

[Joel Sherrill]

On Thu, 21 Aug 1997, Niklas Hallqvist wrote:

> > Message-Id: <16063846900569@DOMAIN_H>
> > 
> > Thanks Joel.
> > The fault was with the MACHINE_STATE_SAVE etc functions pulling in an asm (as 
> > you said). So I've got rid of that the hard way by editing config/m68k/m68k.h .
> > But I don't think that was the way to cure it as I now get an assembler error 
> > when __main is extracted from libgcc2.c because the compiler makes the label 
> > p_%2: which the assembler rejects. It looks like there is a define missing or 
> > set wrrong which is causing inbuilt bits to think it's driving a different 
> > assembler. 
> > 
> > Clues appreciated. 
> 
> Well there are three different assembler syntaxes to choose from if I
> recall correctly (it was quite some time ago I had to deal with
> anything but MIT syntax) MOTO, MIT & SGS.

What actual target configuration are you using?

--joel

Re: cross compiling to m68k

[Jon McGugan]

configuration I used was:
configure --target=delta --with-gnu-as --with-gnu-ld

> 
> 
> On Thu, 21 Aug 1997, Niklas Hallqvist wrote:
> 
> > > Message-Id: <16063846900569@DOMAIN_H>
> > > 
> > > Thanks Joel.
> > > The fault was with the MACHINE_STATE_SAVE etc functions pulling in an asm (as 
> > > you said). So I've got rid of that the hard way by editing config/m68k/m68k.h .
> > > But I don't think that was the way to cure it as I now get an assembler error 
> > > when __main is extracted from libgcc2.c because the compiler makes the label 
> > > p_%2: which the assembler rejects. It looks like there is a define missing or 
> > > set wrrong which is causing inbuilt bits to think it's driving a different 
> > > assembler. 
> > > 
> > > Clues appreciated. 
> > 
> > Well there are three different assembler syntaxes to choose from if I
> > recall correctly (it was quite some time ago I had to deal with
> > anything but MIT syntax) MOTO, MIT & SGS.
> 
> What actual target configuration are you using?
> 
> --joel
> 
> 

Regards

Jon

Re: cross compiling to m68k

[Niklas Hallqvist]

> Message-Id: <16063846900569@DOMAIN_H>
> 
> Thanks Joel.
> The fault was with the MACHINE_STATE_SAVE etc functions pulling in an asm (as 
> you said). So I've got rid of that the hard way by editing config/m68k/m68k.h .
> But I don't think that was the way to cure it as I now get an assembler error 
> when __main is extracted from libgcc2.c because the compiler makes the label 
> p_%2: which the assembler rejects. It looks like there is a define missing or 
> set wrrong which is causing inbuilt bits to think it's driving a different 
> assembler. 
> 
> Clues appreciated. 

Well there are three different assembler syntaxes to choose from if I
recall correctly (it was quite some time ago I had to deal with
anything but MIT syntax) MOTO, MIT & SGS.

It looks like you might have your assembler setup for SGS syntax or
something, and are generating MIT.  Well, grep for SGS in
config/m68k/* and I think you will get some hints.  I also recall SGS
had another argument ordering on cmp instructions.  Anyway, watch your
compiler and assembler config closely so you get them to speak the
same syntax.

This is all from memory left from a long time ago, save your flames if
I have got it wrong.

Niklas

Re: cross compiling to m68k

[Jon McGugan]

Thanks Joel.
The fault was with the MACHINE_STATE_SAVE etc functions pulling in an asm (as 
you said). So I've got rid of that the hard way by editing config/m68k/m68k.h .
But I don't think that was the way to cure it as I now get an assembler error 
when __main is extracted from libgcc2.c because the compiler makes the label 
p_%2: which the assembler rejects. It looks like there is a define missing or 
set wrrong which is causing inbuilt bits to think it's driving a different 
assembler. 

Clues appreciated. 
> 
> 
> On Wed, 20 Aug 1997, Jon McGugan wrote:
> 
> > I have tried to cross compile the snapshot to target M68K. 
> > This works for the standard gcc package.
> > With egcs I get errors from the gnu assembler when the make gets to libgcc2 and 
> > module bb
> > The errors relates to constructions of form:
> > #APP
> >         movem.l  d0-d3,sp@-
> > #NO APP
> > 
> > being inserted into the assembler file.
> > Does anyone know why:
> > 1)  these are put in
> > 2) In wrong syntax for GAS - should be movem.l %d0-%d3,%sp@-
> > 
> > The rest of the assembler code produced is correct
> > 
> > And, of course, more importantly how to overcome the problem.
> 
> This looks like it came from an embedded assembly statement in a C file. 
> I do not know which target configuration you are using but it appears to
> require the % in front of register names.  You need to identify the C
> file.  Then you will find something like "asm ("movem...")" or "asm
> volatile( "movem...")".   Once you find this statement, you will need to
> change it to include % in front of the register names.  You will probably
> have to put %% since % is a special character in the embedded asm format.
> Here is an example from RTEMS which shows how we disable interrupts:
> 
> #define m68k_disable_interrupts( _level ) \
>   asm volatile ( "movew   %%sr,%0\n\t" \
>                  "orw     #0x0700,%%sr" \
>                     : "=d" (_level))
> 
> I think this has enough in it to help you out. I hope this helps you find
> the problem.
> 
> --joel
> Joel Sherrill                    Director of Research & Development
> joel@OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (205) 722-9985
> 
> 
> 
> 
> 

Regards

Jon

Re: cross compiling to m68k

[Ian Lance Taylor]

   Date: Wed, 20 Aug 1997 10:25:06 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   > I have tried to cross compile the snapshot to target M68K. 
   > This works for the standard gcc package.
   > With egcs I get errors from the gnu assembler when the make gets to libgcc2 and 
   > module bb
   > The errors relates to constructions of form:
   > #APP
   >         movem.l  d0-d3,sp@-
   > #NO APP
   > 
   > being inserted into the assembler file.

   This looks like it came from an embedded assembly statement in a C file. 

Actually, in this case, I believe it's from the definition of
MACHINE_STATE_SAVE in config/m68k/m68k.h.  That macro requires %/
before the register names, as in longlong.h.  The same is true of
MACHINE_STATE_RESTORE, and perhaps others.

Ian

Re: cross compiling to m68k

[Joel Sherrill]

On Wed, 20 Aug 1997, Jon McGugan wrote:

> I have tried to cross compile the snapshot to target M68K. 
> This works for the standard gcc package.
> With egcs I get errors from the gnu assembler when the make gets to libgcc2 and 
> module bb
> The errors relates to constructions of form:
> #APP
>         movem.l  d0-d3,sp@-
> #NO APP
> 
> being inserted into the assembler file.
> Does anyone know why:
> 1)  these are put in
> 2) In wrong syntax for GAS - should be movem.l %d0-%d3,%sp@-
> 
> The rest of the assembler code produced is correct
> 
> And, of course, more importantly how to overcome the problem.

This looks like it came from an embedded assembly statement in a C file. 
I do not know which target configuration you are using but it appears to
require the % in front of register names.  You need to identify the C
file.  Then you will find something like "asm ("movem...")" or "asm
volatile( "movem...")".   Once you find this statement, you will need to
change it to include % in front of the register names.  You will probably
have to put %% since % is a special character in the embedded asm format.
Here is an example from RTEMS which shows how we disable interrupts:

#define m68k_disable_interrupts( _level ) \
  asm volatile ( "movew   %%sr,%0\n\t" \
                 "orw     #0x0700,%%sr" \
                    : "=d" (_level))

I think this has enough in it to help you out. I hope this helps you find
the problem.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

cross compiling to m68k

[Jon McGugan]

I have tried to cross compile the snapshot to target M68K. 
This works for the standard gcc package.
With egcs I get errors from the gnu assembler when the make gets to libgcc2 and 
module bb
The errors relates to constructions of form:
#APP
        movem.l  d0-d3,sp@-
#NO APP

being inserted into the assembler file.
Does anyone know why:
1)  these are put in
2) In wrong syntax for GAS - should be movem.l %d0-%d3,%sp@-

The rest of the assembler code produced is correct

And, of course, more importantly how to overcome the problem.

Regards

Jon