On Tue, 6 Jan 2015, James Greenhalgh wrote:
> > -The @file{.md} file for a target machine contains a pattern for each
> > -instruction that the target machine supports (or at least each instruction
> > -that is worth telling the compiler about). It may also contain comments.
> > -A semicolon causes the rest of the line to be a comment, unless the
> > semicolon
> > -is inside a quoted string.
>
> A detailed description of the syntax of a .md file does not belong in an
> introduction. It is a deficiency of this patch set that this text is not
> added back elsewhere. Do you have any suggestions of where the text could
> sensibly go?
A section that describes the lexical structure and syntax of .md files?
> > @@ -54,50 +54,60 @@ See the next chapter for information on the C header
> > file.
> > @node Overview
> > @section Overview of How the Machine Description is Used
> >
> > -There are three main conversions that happen in the compiler:
> > +There are four main conversions that happen in the compiler:
>
> The previous text is inaccurate.
It would seem better not to give a specific number (just as we've tried to
keep down the number of references in the web pages to a particular
version control system).
> I prefer the text below. We lose "without regard for the RTL template or
> operand constraints", but this is contradictory anyway, as the RTL template
> is used when expanding a define_insn.
I believe the point of "without regard for the RTL template or operand
constraints" is that when e.g. expanding addition of two SImode values,
the RTL template from the addsi3 pattern is inserted blindly, even if that
RTL looks nothing like RTL for an addition; nothing looks for an (add:SI)
pattern, or generates such RTL if it's not what the RTL for addsi3 looks
like.
I should point out, if giving paragraph-by-paragraph rationale, that *each
revision of the patch* needs to give the paragraph-by-paragraph rationale
corresponding to that revision of the patch - that a piece passed over for
one revision by one reviewer may be reviewed in more detail later or by
another reviewer. This may be easier with a finer-grained division of the
patch submission.
--
Joseph S. Myers
jos...@codesourcery.com
