Re: [discuss] AMD x86-64 GCC development

[Jan Hubicka <jh at suse dot cz>]

[suse.cz is down for some purpose, you can reply me to hubicka@freesoft.cz
instead.]
> Yes, but that's *exactly* why it's so important not to have a separate tree
> for too long because there is *other* development going on for the i386 and
> the longer the two developments are separate, the mroe trouble it will be
> to merge them.
I am regualry mergning the gcc snapshots to our CVS to avoid these problems.
Most of current i386 backend development is merging of x86-64 bits that are
independent on x86-64 itself tought.

> As to stability, I see the point, but if there's going to have to be a
> space hit in the compiler (which I don't understand, since MD-related
> stuff is usually a small fraction of the size), I think it's best to have
The insn-attrtab.c is currently over 1MB on i386 backend.  In our tree it is
1.7MB, that makes about 500kb hit on code size of optimized compiler only in
this file.  Overall the cost os about 40% of code.
> that hit earlier rather than later.
I think this can be avoidable.  I've sent patches to genattrtab to avoid
unnecesary insn-attrtab bloat, but the main bit got suck during review
process (even when most of code is in already).

It can be nice to preprocess md files to allow generate i386-only, x86-64-only
and i386/x86-64 compiler from the same md file.  I've heard that some progress
on this is going on. If not, I am able to implement this myself once
general design is discussed.

I don't want to keep 3.0 in state having 1MB of dead code in the i386 backend,
since I didn't get far enought before feature freeze.

Honza