This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 8-bit processors back-end optimizations


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]