Re: Possible change to gen* for splits

Re: Possible change to gen* for splits

[Richard Kenner]

    Actually, since I can do lookahead, how about:

	"condition"

	"&& reload_completed"

    That seems to better reflect the actual relationship of the two conditions.

I guess that works since it would be meaningless were there not a
previous condition, but it seems sort of "odd" to me, though I can't say
exactly why.  My concern is in picking a syntax where it's obvious the
is some relation between the two conditions to somebody who might not
have carefully poured through all the documentation.

Re: Possible change to gen* for splits

[Richard Earnshaw]

>     Actually, since I can do lookahead, how about:
> 
> 	"condition"
> 
> 	"&& reload_completed"
> 
>     That seems to better reflect the actual relationship of the two conditions.
> 
> I guess that works since it would be meaningless were there not a
> previous condition, but it seems sort of "odd" to me, though I can't say
> exactly why.  My concern is in picking a syntax where it's obvious the
> is some relation between the two conditions to somebody who might not
> have carefully poured through all the documentation.

Maybe it would be better if the "glue" were to appear outside of the 
double quotes.  Eg (though I haven't thought the implications of this 
particular syntax through):

	+"&& reload_completed"

The plus sign would indicate that the two sets of conditions should be 
concatenated together.  It would also enable other terms in the 
concatenation, eg +"|| some_other_constraint".

Doing it this way would avoid the need to try and parse part of the 
contents of the condition string -- which strikes me as error-prone.

R.

Re: Possible change to gen* for splits

[Richard Henderson]

On Thu, Mar 16, 2000 at 05:05:29PM +0000, Richard Earnshaw wrote:
> Maybe it would be better if the "glue" were to appear outside of the 
> double quotes.  Eg (though I haven't thought the implications of this 
> particular syntax through):
> 
> 	+"&& reload_completed"

Can't do that without hacking up read_rtx.  We're only prepared
for certain types of tokens.


r~

Re: Possible change to gen* for splits

[Richard Earnshaw]

> On Thu, Mar 16, 2000 at 05:05:29PM +0000, Richard Earnshaw wrote:
> > Maybe it would be better if the "glue" were to appear outside of the 
> > double quotes.  Eg (though I haven't thought the implications of this 
> > particular syntax through):
> > 
> > 	+"&& reload_completed"
> 
> Can't do that without hacking up read_rtx.  We're only prepared
> for certain types of tokens.
> 
> 
> r~


Ok, how about forgetting the second constraint altogether, and having a 
single constraint like

"foo && (RECOG || bar)"

RECOG could always be #define'd to 1 when recognizing a pattern, and to 
zero when the constraint is used as a split.  The optimizer can then 
simplify the expression as required.

Re: Possible change to gen* for splits

[Michael Meissner]

On Mon, Mar 16, 1970 at 11:43:40AM -0500, Richard Kenner wrote:
>     Actually, since I can do lookahead, how about:
> 
> 	"condition"
> 
> 	"&& reload_completed"
> 
>     That seems to better reflect the actual relationship of the two conditions.
> 
> I guess that works since it would be meaningless were there not a
> previous condition, but it seems sort of "odd" to me, though I can't say
> exactly why.  My concern is in picking a syntax where it's obvious the
> is some relation between the two conditions to somebody who might not
> have carefully poured through all the documentation.

I think having the && implicit would be better:

	"condition"

	"reload_completed"

(and obviously if the second condtion is "", the gen* would translate it to 1).

-- 
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Possible change to gen* for splits

[Richard Henderson]

On Thu, Mar 16, 2000 at 11:34:21AM -0500, Richard Kenner wrote:
>     Actually, since I can do lookahead, how about:
> 
> 	"condition"
> 
> 	"&& reload_completed"
> 
> I guess that works since it would be meaningless were there not a
> previous condition, but it seems sort of "odd" to me, though I can't say
> exactly why.

I quite like it.

> My concern is in picking a syntax where it's obvious the
> is some relation between the two conditions to somebody who might not
> have carefully poured through all the documentation.

Exactly.  Which is why I like a leading && so much.  Pick
any other marker and it's going to be meaningless unless
you've read all the documentation.  Use && and you're at
least using the right C operator to describe what happens.


r~

Re: Possible change to gen* for splits

[Richard Kenner]

    I think having the && implicit would be better:

	"condition"

	"reload_completed"

The reason I don't like that is that it isn't obvious to the casual reader
that the second condition is really the "&&" of the two of them.

Re: Possible change to gen* for splits

[Richard Kenner]

    Maybe it would be better if the "glue" were to appear outside of the 
    double quotes.  Eg (though I haven't thought the implications of this 
    particular syntax through):

	+"&& reload_completed"

No, that can't work due to the way RTL expressions are parsed.

Re: Possible change to gen* for splits

[Richard Kenner]

    (define_insn_and_split "name"
      ...normal insn...
      [split pattern]
      "split condition"
      "split preparation statements"
    ) 

I like this idea.

    I'd also like it to grok "* condition" for the split condition, which
    means "append condition to whatever condition was in the insn" so that
    the common case of:

I like this idea too, but don't like using '*' since it has other meanings
in the MD file already. How about '|' or '^'?

Re: Possible change to gen* for splits

[Clinton Popetz]

On Thu, Mar 16, 2000 at 08:50:15AM -0500, Alan Lehotsky wrote:
> At 8:32 -0500 3/16/00, Richard Kenner wrote:
> >     (define_insn_and_split "name"
> >       ...normal insn...
> >       [split pattern]
> >       "split condition"
> >       "split preparation statements"
> >     )
> >
> >I like this idea.
> >
> >     I'd also like it to grok "* condition" for the split condition, which
> >     means "append condition to whatever condition was in the insn" so that
> >     the common case of:
> >
> >I like this idea too, but don't like using '*' since it has other meanings
> >in the MD file already. How about '|' or '^'?
> 
> 
> 	Don't use any character that could be a prefix operator!
> 
> 	The period would be okay (although not very legible).  How
> 	about '%'.  It's big, it's obvious and it's an illegal
> 	unary operator AFAIK.

Actually, since I can do lookahead, how about:

	"condition"

	"&& reload_completed"

That seems to better reflect the actual relationship of the two conditions.

				-Clint

Possible change to gen* for splits

[Clinton Popetz]

I'm wondering if it's possible to eliminate some of the redundancy in the md
files w.r.t. splits.  It seems we often have an define_insn that forces a
split, followed by a define_split with the same rtl template.  For instance,
from sparc.md:

(define_insn "*neg_snesi_zero"
  [(set (match_operand:SI 0 "register_operand" "=r")
	(neg:SI (ne:SI (match_operand:SI 1 "register_operand" "r")
		       (const_int 0))))
   (clobber (reg:CC 100))]
  "! TARGET_LIVE_G0"
  "#"
  [(set_attr "length" "2")])

(define_split
  [(set (match_operand:SI 0 "register_operand" "")
	(neg:SI (ne:SI (match_operand:SI 1 "register_operand" "")
		       (const_int 0))))
   (clobber (reg:CC 100))]
  ""
  [(set (reg:CC_NOOV 100) (compare:CC_NOOV (neg:SI (match_dup 1))
					   (const_int 0)))
   (set (match_dup 0) (neg:SI (ltu:SI (reg:CC 100) (const_int 0))))]
  "")



This is pretty common, and it's somewhat of a maintenance problem (e.g. if I
add a clobber to the insn, I have to add a clobber to the split.  I'm running
into this trying to add clobbers for the xer register to every insn and split
in rs6000.md that set the carry bit.  Yuck.)  Since the two rtl templates have
to match for the split to work, it seems overkill to type them twice.  By
having gen* grok this:

(define_insn_and_split "name"
  ...normal insn...
  [split pattern]
  "split condition"
  "split preparation statements"
) 

the above two patterns would be:

(define_insn_and_split "*neg_snesi_zero"
  [(set (match_operand:SI 0 "register_operand" "=r")
	(neg:SI (ne:SI (match_operand:SI 1 "register_operand" "r")
		       (const_int 0))))
   (clobber (reg:CC 100))]
    "! TARGET_LIVE_G0"
  "#"
  [(set_attr "length" "2")]
  [(set (reg:CC_NOOV 100) (compare:CC_NOOV (neg:SI (match_dup 1))
					   (const_int 0)))
   (set (match_dup 0) (neg:SI (ltu:SI (reg:CC 100) (const_int 0))))]
  ""
  ""
)

Does this seem reasonable/useful?  I'd also like it to grok "* condition" for
the split condition, which means "append condition to whatever condition was in
the insn" so that the common case of:

(define_insn 
 [pattern]
 "complex_condition"
 ...
)

(define_split 
 [pattern]
 [split]
 "complex_condition && reload_completed"
 ...
)

could be 

(define_insn_and_split
 [pattern]
 "condition"
 ...
 [split]
 "* && reload_completed"
) 

The above change would be worth several hundred lines in rs6000.md, so I'd
be willing to do the work to gen*, as it would save me time in the long run.

				-Clint

Re: Possible change to gen* for splits

[Jeffrey A Law]

  In message < 20000310092128.A17714@cpopetz.com >you write:
  > I'm wondering if it's possible to eliminate some of the redundancy in the
  > md files w.r.t. splits.  It seems we often have an define_insn that forces 
a
  > split, followed by a define_split with the same rtl template.  For instance
It seems like a good idea to me -- and it would probably simplify several
ports to varying degrees.  More importantly it helps on the maintenance side
by ensuring that the two patterns are always in sync.


  > Does this seem reasonable/useful?  I'd also like it to grok "* condition"
  > for the split condition, which means "append condition to whatever
  > condition was in the insn" so that the common case of:
Seems reasonable too, though I would use something that wasn't a C operator.
One could possibly have a condition like *pointer on a splitter condition.
jeff