This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [discuss] AMD x86-64 GCC development
- To: jh at suse dot cz
- Subject: Re: [discuss] AMD x86-64 GCC development
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Sun, 12 Nov 00 12:56:35 EST
- Cc: discuss at x86-64 dot org, gcc at gcc dot gnu dot org
Problem is that unline completely new chip, the x86-64 backend is done
in the existing i386 backend
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.
Are you at least picking up changes made to the FSF tree on a regular
(hopefully at least weekly) basis? That will make things easier.
and active development on it introduces breakage to i386 backend
too. Stability of the i386 is important for the other developers. With
current scheme of not having conditionized compilation of machine
description, the patterns useless for i386, but required for x86-64
increases size of the i386 compiler by considerable amount. Thats
another purpose why I don't want to polute 3.0 with unfinished x86-64
support.
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
that hit earlier rather than later.