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)


Vladimir Makarov <vmakarov@redhat.com> writes:

  > Dan Nicolaescu wrote:
  > > 
  > > Vladimir Makarov <vmakarov@redhat.com> writes:
  > > 
  > >   > Dan Nicolaescu wrote:
  > >   > >
  > >   > > Vladimir Makarov <vmakarov@redhat.com> writes:
  > >   > >
  > >   > >   > Dan Nicolaescu wrote:
  > >   > >   > >
  > >   > >   > > [snip]
  > >   > >   > >
  > >   > >   > > I have a comment on the constructs used to describe the pipeline, it
  > >   > >   > > uses regular expressions in a string.
  > >   > >   > >
  > >   > >   > > That is a little bit not-orthogonal with the rest of the .md file, as
  > >   > >   > > regexps are an infix notation and the rest of .md language is a prefix
  > >   > >   > > language.
  > >   > >   > >
  > >   > >   > > IMO something like:
  > >   > >   > >
  > >   > >   > > (define_insn_reservation "mult" 4 (eq_attr "cpu" "mult")
  > >   > >   > >                          (sequence "i1_pipeline"  (nothing 3)
  > >   > >   > >                                    (or "port_0"  "port1")))
  > >   > >   >
  > >   > >   > Hi, Dan.
  > >   > >   >
  > >   > >   > Sequence requires list of rtl expressions.  That means you should write
  > >   > >   >
  > >   > >   > (sequence (const_string "i1_pipeline")  (nothing 3)
  > >   > >   >
  > >   > >   > > is a little bit more understandable and probably easier to parse
  > >   > >   > > than:
  > >   > >   > >
  > >   > >   > > (define_insn_reservation "mult" 4 (eq_attr "cpu" "mult")
  > >   > >   > >                          "i1_pipeline, nothing*3, (port_0 | port1)")
  > >   > >   > >
  > >   > >   > > (stolen from your example)
  > >   > >   > >
  > >   > >   > > Of course this could turn into a religious discussion...
  > >   > >   > > Just wondering what everybody thinks...
  > >   > >   >
  > >   > >   >   RTL has some constructions which could be used to describe the
  > >   > >   > reservations (sequence, parallel etc.). If we are using rtl
  > >   > >   > constructions to describe the reservation, it will be too verbose.
  > >   > >   > Typical example is using (const_string "a") instead of "a".  A 200 lines
  > >   > >   > description (of one VLIW processor) would be 400-600 lines in such
  > >   > >   > case.  Also this description would be not readable.  Actually, the first
  > >   > >   > design used such approach and was rejected.
  > >   > >   >
  > >   > >   >   If we don't use existing RTL constructions, we need to create new ones
  > >   > >   > slightly different to the existing constructions which is also not
  > >   > >   > good.  So I'd choose brevity and simplicity to orthogonality in this
  > >   > >   > case.  That is not only my opinion.
  > >   > >
  > >   > > You could create a few new constructs: (pipe_sequence ... )
  > >   > >                                   or (pseq ... )
  > >   > >
  > >   > > You just need 3-4 of them. (You introduce new constructs with the
  > >   > > regexp syntax anyway, so I don't think this is a problem).
  > >   > >
  > >   >
  > >   >   Dan, it will be too verbose.  Even if you don't use the existing rtl
  > >   > construction,  you need nested constructions which is rtl expressions.
  > >   > It results in that you should always use for each name (const_string
  > >   > "...").  If we don't use the nested constructions, the model will be too
  > >   > primitive.
  > > 
  > > You don't have to. You are writing a new reader anyway, so you can
  > > make it read whatever you want. So the change is just from a regexp
  > > infix format to a prefix parenthesized format.
  > 
  > My reader is standard RTL reader.  You need only to define templates in
  > rtl.def which says about parameter types. 

I see. 

  >  If you define parameter type
  > as a string, you can not use expression (the nested constructions).  If
  > you define the paarmeter type as an expression, you should use
  > (constant_string "...").  Unless somebody writes new insfrastructure for
  > RTL which permits to define union of types, you should use
  > (constant_string "...").

A _hacky_ way to do it might be to do what define_constants does (in
rtl.c:read_rtx): hook in it's own reader. (maybe it would be a little
more complicated than that...)

But the real question is if people beleive that it's better to have a
lispish description for the pipelines rather than use a regexp in a
string, otherwise this discussion is moot...

        --dan


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