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

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

On Mon, Aug 06, 2007 at 04:21:24PM +0200, Uros Bizjak wrote:
> Hello!
> 
> >   What I mean when I ask you to mention benefits of merging ia16 into i386
> >is things like
> >
> > - will it make the compiler easier to maintain?
> > - will it make the compiler run faster?
> > - will it make the compiler use less memory?
> > - will it make the compiler produce better code?
> > - will it make the compiler easier to use?
> >
> >but feel free to add anything else that comes to your mind.
> >  
> 
> IMO, point 1 outweighs all other points.

   Code quality matters a lot to me, otherwise I probably could have lived
with bcc.

   When it comes to maintaining a combined ia16/i386 back end, I'm not
thrilled with the prospect of having to do a bootstrap and test cycle of
i386 for each and every change to the ia16 parts. IMO this is a major point
against a merge.

> The 16bit port is not something 
> I'd consider heavily used port, so my main concern here would be a 
> possible bitrot of the contributed code. To avoid this, I think that as 
> much as possible code should be shared between much tested i386 and 
> ix86_16 parts.

   It only helps a little. For example, powerpc-unknown-eabisim hasn't built
for a few months now, despite sharing much code with targets such as
powerpc64-unknown-linux-gnu, powerpc-ibm-aix5.2.0.0 and
powerpc-apple-darwin8.5.0 which are built and tested daily.

> This way, all improvements to i386 backend would 
> automatically be available to ix86_16 backend. And since quite some 
> people look into i386 code, much more eyeballs will stare at your code 
> too, surely much more than if your code would be hidden in some obscure 
> directory.

   config/i386 is 75984 lines while config/ia16 is 6372 lines. There is a
risk that the ia16 bits drown in the i386 bits.

> Please also remember that quite some of your 
> ideas/improvements based on your (not even released) backend  were added 
> to generic i386 backend, so both backends would benefit from code share. 

   In other words, you're trying to coax me into becoming an i386
maintainer. :-)

> As an example, existing MIPS backend covers all targets from one code 
> base, ranging from embedded 16bit to 64bit targets.

   I'm no MIPS expert, but isn't MIPS16 mainly a compact instruction
encoding, with a reduction in the available instructions and two-operand
instructions to make the encoding fit into 16 bits?
 
> If you choose this approach, I can help you to factor out common code to 
> merge both backends.

   Factoring out some common code sounds a lot better to me than an actual
merge. There are some pieces of code which could probably be shared:

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.

   This may not look like a lot, but it centers around the only common
characteristics of the x86 family: The mod r/m fields of an instruction, the
effect that instructions have on the condition codes and the x87.

   Stage 3 starts in three weeks. How much is it realistic to achive before
then?

-- 
Rask Ingemann Lambertsen