On 07/06/2018 10:20 AM, Richard Sandiford wrote:
> Paul Koning <paulkon...@comcast.net> writes:
>> @@ -8615,6 +8639,34 @@ so here's a silly made-up example:
>> "")
>> @end smallexample
>>
>> +There are two special macros defined for use in the preparation statements:
>> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
>> +as a statement.
>> +
>> +@table @code
>> +
>> +@findex DONE
>> +@item DONE
>> +Use the @code{DONE} macro to end RTL generation for the peephole. The
>> +only RTL insns generated as replacement for the matched input insn will
>> +be those already emitted by explicit calls to @code{emit_insn} within
>> +the preparation statements; the replacement pattern is not used.
>> +
>> +@findex FAIL
>> +@item FAIL
>> +Make the @code{define_peephole2} fail on this occasion. When a
>> @code{define_peephole2}
>> +fails, it means that the replacement was not truly available for the
>> +particular inputs it was given. In that case, GCC may still apply a
>> +later @code{define_peephole2} that also matches the given insn pattern.
>> +(Note that this is different from @code{define_split}, where @code{FAIL}
>> +prevents the input insn from being split at all.)
>> +@end table
>> +
>> +If the preparation falls through (invokes neither @code{DONE} nor
>> +@code{FAIL}), then the @code{define_peephole2} uses the replacement
>> +template.
>> +
>> +
>> @noindent
>> If we had not added the @code{(match_dup 4)} in the middle of the input
>> sequence, it might have been the case that the register we chose at the
>
> Double empty line.
>
> OK otherwise, thanks. (Think this counts as a gen* patch.)
:-) Close enough for me.
Jeff
