This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 2nd try for patch for automaton based pipeline hazard recognizer (part #1)
- To: Vladimir Makarov <vmakarov at toke dot toronto dot redhat dot com>
- Subject: Re: 2nd try for patch for automaton based pipeline hazard recognizer (part #1)
- From: law at redhat dot com
- Date: Mon, 18 Jun 2001 10:51:53 -0700
- cc: gcc-patches at gcc dot gnu dot org, geoffk at cygnus dot com
- Reply-To: law at redhat dot com
In message <200106131859.OAA30718@toke.toronto.redhat.com>you write:
> Because transition from old descriptions to new ones is assumed to
> be long process (or will never finish fully), the patch permits to use
> old description and PHR code based on it as new one too. You could
> use old description for one processor submodels and new one for the
> rest processor submodels. You only need to define correctly macro
> USE_AUTOMATON_PIPELINE_INTERFACE. By default if there are old and new
> one description in md file, the new one is used.
Instead of defining USE_AUTOMATON_PIPELINE_INTERFACE, it seems to me that
triggering that path should be based on the existance of a
define_insn_reservation for the current cpu model we're compiling for.
It's also not clear to me what happens when we have an MD file which supports
multiple cpu variants and some of those variants use the old model and some
the new model. Will your code properly switch between the old and new code
automatically based on what processor the user is compiling for?
And while I haven't looked at the code in detail, the first thing that jumps
out to me is the amazing number of #ifdefs for old vs new model (which
indicates to me that we do not automatically select which model to use based
on what chip we're compiling for).
I'd consider that a huge problem for the integration of this code. Unless
we're going to take the approach that a port must be converted all at once.
jeff