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