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

[Jan Hubicka <jh@suse.cz>]

> 
>    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.

Well, given that there seems to be mostly consensus about merging the
backend, I guess it is way to go. If you are interested to do the job, I
will be happy to review the incremental patches (at least till 22nd when
I am leaving for 8 days).
I would propose the plan of getting initial changes into mainline before
stage2 closes and continuing on the branch.  Definitly the changes for
branch can be reviewed making merge at stage1 easy.
> 
> > > >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.

We would have to stabilize fair amount of i386 internal interfaces (ie
pattern names for various instructions, macros defined and such) to get
the common expanders working.  This does not seem terribly practical
even if it is certainly doable.

Honza
> 
> -- 
> Rask Ingemann Lambertsen