This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 8-bit processors back-end optimizations
- To: wilson at cygnus dot com
- Subject: Re: 8-bit processors back-end optimizations
- From: chris at lslsun dot epfl dot ch (Christian Iseli)
- Date: Tue, 2 Sep 1997 16:01:54 +0200
- Cc: egcs at cygnus dot com
> No. They are rare. There are a handful of ports to 16 bit or mixed 8/16 bit
> machines (e.g. h8300, mn10200, pdp11) in the gcc sources. I can only recall
> one port to a pure 8 bit machine, the 6811, unfortunately, that port will
> never make it into gcc because we can't get copyright assignments from the
> authors. You might be able to find it on the net somewhere though.
I see. I have the 6811 port lying around somewhere.
> The main problem with 8 bit targets is the lack of registers. If you don't
> have 8 registers or so, then you won't be able to get gcc working without
> resorting to tricks. The 6811 port for instance pretended that it had
> registers in zero page memory. This gave inefficient code in some cases, but
> it apparently did work.
I noticed that. I have 14 usable registers and still find it to be precious few,
especially since any pointer uses two at a time, and the stack pointer also
freezes two of them.
> There is code in the C front end to handle this. If the operator would give
> the same result in the smaller mode, then the C front end will try to generate
> RTL that uses the smaller mode. See the `shorten' code in build_binary_op
> in c-typeck.c. There are however quite a few cases that can't be shortened
> because this may generate different results for some inputs.
I have taken a look at the code. It does its thing before even generating
RTL (unless I'm mistaken) and usually leaves out division, modulo and
shifting operations.
> The combine pass may also optimize away some of this stuff, if it can figure
> out that the extra bits in the result are not needed.
The combiner does a nice enough job, except that it fails to optimize things
like:
(set (reg:HI ExtA) (op:HI (sign_extend:HI (reg:QI B)) (sign_extend:HI (reg:QI C))))
(set (reg:QI A) (subreg:QI (reg:HI ExtA) 1))
into:
(set (reg:QI A) (op:QI (reg:QI B) (reg:QI C)))
Would that be a good idea to teach the combiner about these combinations
(provided proper precautions be taken to avoid arithmetic errors)?
Christian