This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 2nd try for patch for automaton based pipeline hazard recognizer (part #1)


  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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]