Re: Reload patch to improve 386 code

Re: Reload patch to improve 386 code

[Jakub Jelinek]

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

Re: ANSI C++ support periority?

[Jason Merrill]

>>>>> Amos Shapira <amos@gezernet.co.il> writes:

> My main interest in egcs is the need for a good *STandard ANSI C++*
> compiler.  Mainly for Linux (Intel platform for now).  Can anyone tell
> me where does this item stand in the list of periorities of egcs?

The priorities of egcs are whatever people work on.  Cygnus is committed to
development of G++, whether gcc2 or egcs-based.  egcs releases will include
the current C++ frontend.

Jason

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "meissner" == meissner  <meissner@cygnus.com> writes:

 meissner> Sounds like it won't work too well on Canadian Crosses
 meissner> where build, host, and target machines are all different.

I can only say that bug reports for cross-g77 have always been
welcome.  There has been a fix made in the development version for
cygwin defining `unix' AFAIR and there were some problems which
appeared to be due to bugs in cygwin which I think should be addressed
there.  (The term `criss-cross' was coined in g77 circles
independently on each side of the Atlantic as a less obscure
alternative to Canadian.)

 meissner> | I don't understand why C++ should stick stuff in libgcc anyhow -- why
 meissner> | isn't its runtime kept separate like objc and fortran?

 meissner> Because GNU C supports static constructors and destructors
 meissner> as well with __attribute__((__constructor__)).

It seems wrong to me if you need to build c++ to get that in C.
__constructor__ is useful for runtime configuration with g77 (and
other languages?) but I hadn't realized the dependency, damn.

Re: egcs: A new compiler project to merge the existing GCC forks (fwd)

[Dave Love]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

 H> I downloaded this a few days ago - compiles and runs without any
 H> problems on a PentiumPro Linux 2.0.30 (Redhat 4.2) system - but:

 H> execution speed (floating point) of a test case (mdbench) 

Note that mdbnch (at least the version I know) is in double precision.
Thus other performance considerations are typically overshadowed on
ppro by the double alignment problems.  See the g77 manual.

 H>  - I am back right now to the old
 H> stuff, unless I get to hear a convincing reason why to switch.

I doubt it's wise to use the g77 in egcs seriously at least until it's
based on a version that's completed alpha testing for g77 0.5.21.

Re: bootstrapping problems with native compiler

[Jason Merrill]

>>>>> Dave Love <d.love@dl.ac.uk> writes:

> It seems wrong to me if you need to build c++ to get that in C.
> __constructor__ is useful for runtime configuration with g77 (and
> other languages?) but I hadn't realized the dependency, damn.

You don't need C++ for that.  Only the major runtime stuff is built with
g++ (RTTI and EH support code).

Jason

Re: double alignment patch for x86

[Jeffrey A Law]

  In message <E0x0Aav-0001rY-00.1997-08-17-21-02-33_pgcc_forever_@cerebro>you w
rite:
  > Here is my double alignment patch, this time relative to egcs-ss-970814...
  > 
  > It improves performance *much* on the x86...
HJ has already submitted this patch.  I'd like to hear from Stan Cox
before doing anything with it since he's the x86 maintainer.

Also, do you have a copyright assignment on file with the FSF?

jeff

ANSI C++ support periority?

[Amos Shapira]

Hello,

My main interest in egcs is the need for a good *STandard ANSI C++*
compiler.  Mainly for Linux (Intel platform for now).  Can anyone tell
me where does this item stand in the list of periorities of egcs?

Thanks,

--Amos

--Amos Shapira                    | "Of course Australia was marked for
133 Shlomo Ben-Yosef st.          |  glory, for its people had been chosen
Jerusalem 93 805                  |  by the finest judges in England."
ISRAEL       amos@gezernet.co.il  |                     -- Anonymous