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 <3B2E6404.C767C650@redhat.com>you write:
>   >   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.
> OK.  I misunderstood how some of this code works.
> 
>   >
>   > > And while I haven't looked at the code in detail, the first thing that ju
>   > mps
>   > > 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 ba
>   > sed
>   > > 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.
> You're missing my point.  The mess of #ifdefs aren't going to be acceptable.
> They make code far too ugly to contemplate integrating these patches.

  I could remove the #ifdefs. It will require only to generate an empty
automaton interface when only the old pipeline description is used and
analogously an empty old pipeline interface when only the automaton
description is in .md file.  Is it acceptable solution?

Vlad