[doc] describe mode checking for doloop_end pattern

Message ID E1BB48E8-4A94-4E9D-8FC0-C90A9ADBACC3@comcast.net
State New
Headers show
Series
  • [doc] describe mode checking for doloop_end pattern
Related show

Commit Message

Paul Koning Oct. 11, 2018, 9:09 p.m.
Updated with an additional item I just debugged.

Since the code that uses the doloop_end pattern does not check the operand mode as given in the pattern, the pattern itself may need to do this, and that was not documented.  In addition, if the doloop_end pattern is a define_expand, there must be a define_insn (or define_insn_and_split) matching the generated pattern.  I had a define_split instead, and the result was an ICE in loop optimization (loop2_done pass).

This patch adds that information.  It also updates the example to reflect this.

Ok for trunk?

	paul

ChangeLog:

2018-10-11  Paul Koning  <ni1d@arrl.net>

	* doc/md.texi (doloop_end): Document that the pattern code may
	need to check operand mode.

Comments

Jeff Law Oct. 12, 2018, 3:01 a.m. | #1
On 10/11/18 3:09 PM, Paul Koning wrote:
> Updated with an additional item I just debugged.
> 
> Since the code that uses the doloop_end pattern does not check the operand mode as given in the pattern, the pattern itself may need to do this, and that was not documented.  In addition, if the doloop_end pattern is a define_expand, there must be a define_insn (or define_insn_and_split) matching the generated pattern.  I had a define_split instead, and the result was an ICE in loop optimization (loop2_done pass).
> 
> This patch adds that information.  It also updates the example to reflect this.
> 
> Ok for trunk?
> 
> 	paul
> 
> ChangeLog:
> 
> 2018-10-11  Paul Koning  <ni1d@arrl.net>
> 
> 	* doc/md.texi (doloop_end): Document that the pattern code may
> 	need to check operand mode.
OK.
jeff
Paul Koning Oct. 12, 2018, 1:51 p.m. | #2
> On Oct 11, 2018, at 11:01 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 10/11/18 3:09 PM, Paul Koning wrote:
>> Updated with an additional item I just debugged.
>> 
>> Since the code that uses the doloop_end pattern does not check the operand mode as given in the pattern, the pattern itself may need to do this, and that was not documented.  In addition, if the doloop_end pattern is a define_expand, there must be a define_insn (or define_insn_and_split) matching the generated pattern.  I had a define_split instead, and the result was an ICE in loop optimization (loop2_done pass).
>> 
>> This patch adds that information.  It also updates the example to reflect this.
>> 
>> Ok for trunk?
>> 
>> 	paul
>> 
>> ChangeLog:
>> 
>> 2018-10-11  Paul Koning  <ni1d@arrl.net>
>> 
>> 	* doc/md.texi (doloop_end): Document that the pattern code may
>> 	need to check operand mode.
> OK.
> jeff

Thanks.  Committed.

	paul

Patch

Index: md.texi
===================================================================
--- md.texi	(revision 265042)
+++ md.texi	(working copy)
@@ -7619,7 +7619,23 @@  simplified) from the PDP-11 target:
 
 @smallexample
 @group
-(define_insn "doloop_end"
+(define_expand "doloop_end"
+  [(parallel [(set (pc)
+                   (if_then_else
+                    (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
+                        (const_int 1))
+                    (label_ref (match_operand 1 "" ""))
+                    (pc)))
+              (set (match_dup 0)
+                   (plus:HI (match_dup 0)
+                         (const_int -1)))])]
+  ""
+  "@{
+    if (GET_MODE (operands[0]) != HImode)
+      FAIL;
+  @}")
+
+(define_insn "doloop_end_insn"
   [(set (pc)
         (if_then_else
          (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
@@ -7662,10 +7678,23 @@  will be non-negative.
 Since the @code{doloop_end} insn is a jump insn that also has an output,
 the reload pass does not handle the output operand.  Therefore, the
 constraint must allow for that operand to be in memory rather than a
-register.  In the example shown above, that is handled by using a loop
-instruction sequence that can handle memory operands when the memory
-alternative appears.
+register.  In the example shown above, that is handled (in the
+@code{doloop_end_nocc} pattern) by using a loop instruction sequence
+that can handle memory operands when the memory alternative appears.
 
+GCC does not check the mode of the loop register operand when generating
+the @code{doloop_end} pattern.  If the pattern is only valid for some
+modes but not others, the pattern should be a @code{define_expand}
+pattern that checks the operand mode in the preparation code, and issues
+@code{FAIL} if an unsupported mode is found.  The example above does
+this, since the machine instruction to be used only exists for
+@code{HImode}.
+
+If the @code{doloop_end} pattern is a @code{define_expand}, there must
+also be a @code{define_insn} or @code{define_insn_and_split} matching
+the generated pattern.  Otherwise, the compiler will fail during loop
+optimization.
+
 @end ifset
 @ifset INTERNALS
 @node Insn Canonicalizations