Re: New back end ia16: 16-bit Intel x86

[Rask Ingemann Lambertsen <rask@sygehus.dk>]

On Wed, Aug 08, 2007 at 02:21:42PM +0200, Jan Hubicka wrote:
> 
> It seems to me that whole discussin here is going wrong dirrection.
> Discussing pros and cons of maintaining separate ia16 backend relative
> to merged i386 implementation from ia16 only maintainer POV is probably
> not going to bring anything good.  We need to optimizie for overall
> maintainibility of the compiler as a whole.

   Right.

 1) Maintaining the target independent parts will take ever so
slightly more effort with a new back end. The dataflow merge on ia16, for
example, required the obvious regs_ever_live[] -> df_regs_ever_live()
change, nothing more, and something like that doesn't happen very often.

 2) The i386 back end will become more difficult to maintain after a merge.
It is a big back end already and there are not enough maintainers to keep
up. There will be more patches affecting i386 increasing review load.

 3) A 6500 line back end is much easier to maintain than a 76000 line one.

> It all assume that the community interested in ia16 port is willing to
> maintain it or risk the fact that it will be obsoletted and removed in
> future release of GCC. 

   A separate back end is a lot easier to obsolete and remove than one which
is merged into another.

> I seem to be in a minority here however and plan
> to merge 16bit code into i386.c seems good to me too.

   Looking at the few people who have commented on the issue, I notice that
among those who are not i386 maintainers, 100 % are in favour of a merge.
Among the i386 maintainers, 50 % are in favour and 50 % are against. I'll be
working on the 16-bit x86 code and is also against it.

   I'm disappointed to hear arguments along the lines of "-m16 looks cute"
in favour of a merge. From a user's point of view, you could just as well
say "gcc -b ia16-elf" as "gcc -m16" if it matters to you to use the same
front end binary.

> > >1a) ix86_fixup_binary_operands() / ia16_prepare_operands()
> > >1b) ix86_binary_operator_ok() / ia16_arith_operands_p()
> > >2a) ix86_cc_mode() / ia16_select_cc_mode()
> > >2b) ix86_cc_modes_compatible() / ia16_cc_modes_compatible()
> > >2c) ix86_expand_carry_flag_compare() looks interesting.
> > >2d) ix86_expand_int_movcc() too, but I'd rather fix/extend if-conversion.
> > >3a) PLUS/MINUS patterns which make use of the carry flag. For example the
> > >ones I have proposed for fixing PR target/30315.
> > >3b) Multiword PLUS/MINUS where both have room for improvement when it comes
> > >to using the condition codes and i386 could use updating for lower-subreg.
> > >4) x87 instructions.
> 
> I would a lot preffer full sharing of i386 backend over sharing just
> couple of functions as suggested above. Many of those have not terribly
> well defined semantics and depends a lot on i386 backend internals.

   It is possible to define and document semantics. In many cases, it is
even thought of as a good idea.

-- 
Rask Ingemann Lambertsen