Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Oct 1998 07:16:54 +1000
From:      Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Global register variables in gcc and stdio.h?!?
Message-ID:  <98Oct9.071633est.40326@border.alcanet.com.au>

next in thread | raw e-mail | index | archive | help
Wes Peters <wes@softweyr.com> wrote:
>I think you'll find in GCC that "register" is regarded as a weak hint at
>best.
Agreed.

>  The compiler is a whole
>lot smarter about register allocation that you are,

I disagree.  The compiler bases its register allocation on a guess at
the dynamic control flow, based on static data and control flow
analysis.  The actual control flow may be significantly different from
gcc's guess - especially if a lot of code is rarely executed (eg
exception handling code within a function).

Also, gcc does not do any global (cross-function) analysis or
optimisation.  Threaded and bytecode interpreters (ie forth, e-lisp,
java) generally have a small number of global variables which should
be in registers - gcc can't work this out itself (but does have some
extensions to allow then to be manually specified).

Another problem with gcc's register allocation is that it doesn't
re-order local variables within the stack frame.  This means that
variables that can't fit into registers (mostly because they're too
large) sit at the top of the stack frame (closest to the frame
pointer).  Spilt registers go at the end of the stack frame.  The net
result of this is unnecessary code bloat.  For example, on the x86
there is only a choice of 8 or 32-bit offsets - whilst the 32-bit
offset has the same instruction timing, increasing the code size
reduces the cache effectiveness, reducing speed.  On the SPARC you
need a 2 or 3-instruction sequence (and a work register) to access
the variable once you exceed the 12-bit offset.

> especially on an
>architecture where there aren't any.
Actually, on a true 0 or 1-address architecture, register allocation
is trivial.  The real difficulties occur with architectures that have
a small number of registers which aren't quite all general purpose.

Peter
--
Peter Jeremy (VK2PJ)                    peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 9690 5247

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Oct9.071633est.40326>