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

[Vladimir Makarov <vmakarov at redhat dot com>]

law@redhat.com wrote:
> 
>   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 is hard to extract this information (what submodel is described by
automata) from the description.  Although it is possible.  I could do
this in the future.  When it is done, the correct definition of
USE_AUTOMATON_PIPELINE_INTERFACE will be generated.  Now it should be
defined by user.
 
> 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?
>

  Yes, it will.  That is exactly the case when
USE_AUTOMATON_PIPELINE_INTERFACE should be used.  The user should define
the macro whose value is nonzero if the current target submodel pipeline
characteristics are described by automaton.
 
> 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).
> 

  If there is define_insn_reservation, by default automaton based
scheduler is used.  USE_AUTOMATON_PIPELINE_INTERFACE should be defined
if there are automaton based description (for one target submodel) *and*
old descriptions (for another submodel).  If there is only old pipeline
description, USE_AUTOMATON_PIPELINE_INTERFACE also can be undefined.  So
the patch is safe, we can rewrite descriptions step by step.

   We don't need code for automaton based pipeline hazard recognition,
if only old description is present in .md file.  Analogously,
we don't need code for old pipeline hazard recognition, if only
automaton based description is present in .md file.  Therefore so many
#ifdefs are used.  Big number of them shows how the automaton based
pipeline hazard recognizer is different from old one.  Actually, Richard
proposed to extract pipeline hazard recognizers code into separate
file.  I'd only like to make the improvements step by step.

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

The patch is safe, nothing is changed.  The old code is used.  The new
code will be used only when somebody writes an automaton based
description.  In this case, he should define macro
USE_AUTOMATON_PIPELINE_INTERFACE if the old description still exists for
given port.

Vlad