public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* [RFA:] Simplification transformations in semantics.scm
@ 2002-12-06 19:54 Hans-Peter Nilsson
  2002-12-06 20:29 ` Hans-Peter Nilsson
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Hans-Peter Nilsson @ 2002-12-06 19:54 UTC (permalink / raw)
  To: cgen

These simplifications make the CGEN semantic compilation see
somewhat-trivial sets of registers such that the "profile"
support (actually: model unit machinery) marks the right operand
for input and output.  In a .cpu file I have, I use (through
some levels of pmacros) (set (reg h-hw (index-of (operand op))) src)
and the other forms below, which confuse CGEN.

Another way (independently correct AFAICT) to make model support
work for me would be to make the model machinery just ignore the
semantics of the insn and use the operands I *tell it* to use in
the model description, as long as it can find them in the format
description.  Right now inputs and outputs of units are filtered
through whatever is collected from the semantic compilation, so
"op" in (set (reg h-hw (index-of (operand op))) src) is *not*
marked as an output operand.  Subsequently, with (op INT -1) in
a unit output list, the model function for that unit always get
-1 for that operand; op is listed as an input but not as an
output.  Gah!  That's a bug, I think; the unit input and output
should override what the semantic compiler thinks.

In summary, this patch simplifies (as the comments say):

(reg XMODE h-hw (index-of YMODE (operand XMODE op)))
 into
(operand XMODE op)))

(SET (if IFMODE COND ltrue lfalse) src)
 into (for SET = {set, set-quiet}):
(if COND (SET ltrue dst) (SET lfalse dst))

(reg h-hw RMODE (if COND ntrue nfalse))
 into
(if RMODE COND (reg h-hw RMODE ntrue)
	       (reg h-hw RMODE nfalse))
 but only if simplification makes that latter expression
 not take that form, i.e. (if COND (reg...) (reg...))

If you accept this change but consider it so large that
copyright is an issue, we have to work something out, since
there's no copyright agreement between Axis Communications and
Red Hat.  Suggestions welcome.  FWIW, I can only think of this
way to accomplish what I describe above, so I hope to get away
with it as obvious enough.  (I wish, I wish, that Red Hat would
find a way to assign copyright for CGEN to the FSF.  Oh yes, and
peace of earth.)

	* semantics.scm (-simplify-expr-fn) <set, set-quiet, reg>: New
	simplifications.

Index: semantics.scm
===================================================================
RCS file: /cvs/src/src/cgen/semantics.scm,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 semantics.scm
*** semantics.scm	28 Jul 2000 04:11:52 -0000	1.1.1.1
--- semantics.scm	7 Dec 2002 02:48:45 -0000
***************
*** 256,261 ****
--- 256,392 ----
  	   known-val ; (rtx-make 'const 'INT known-val)
  	   #f)))
  
+     ((set set-quiet)
+      ; Transform: (set (if IFMODE COND ltrue lfalse) src)
+      ; into: (if COND (set ltrue dst) (set lfalse dst))
+      ; hoping for further simplification through the
+      ; regno-operand-to-operand simplification below.
+      ; This conditional-lvalue destination is expected from the
+      ; if-transformations below rather than from user input. 
+      ; FIXME: Other conditionals than "if" may be useful
+      ; too.  Add them as the need arises.  Maybe check src for 'if too.
+      (let ((ifexpr (-rtx-traverse (rtx-set-dest expr)
+ 				    'RTX 'DFLT expr 2 tstate appstuff))
+ 	     (src (-rtx-traverse (rtx-set-src expr)
+ 					'RTX 'DFLT expr 3 tstate appstuff)))
+ 	 (if (rtx-kind? 'if ifexpr)
+ 	     (let* ((name (rtx-name expr))
+ 		    (simplified-result
+ 		     (rtx-make
+ 		      'if 'DFLT (rtx-if-test ifexpr)
+ 		      (rtx-make name
+ 				(rtx-if-then ifexpr) src)
+ 		      (rtx-make name
+ 				(rtx-if-else ifexpr) src))))
+ 	       (logit 4
+ 		      "SET -: " (rtx-dump expr) "\n"
+ 		      "SET +: " (rtx-dump simplified-result) "\n")
+ 	       simplified-result)
+ 	     #f)))
+ 
+     ((reg)
+      (if (rtx-reg-number expr)
+ 	 (let* ((regname (rtx-reg-name expr))
+ 		(regmode (rtx-mode expr))
+ 		(regno (-rtx-traverse (rtx-reg-number expr)
+ 				      'RTX 'DFLT expr 3 tstate appstuff)))
+ 	   (case (rtx-name regno)
+ 	     ((index-of)
+ 
+ 	      ; When op is a h-hw, simplify
+ 	      ; (reg XMODE h-hw (index-of YMODE (operand XMODE op)))
+ 	      ; into (operand XMODE op).  For example, (reg h-gr
+ 	      ; (regno Rd)) into Rd, when Rd is a h-gr and likewise
+ 	      ; (reg SI h-gr (regno Rd)) provided that h-gr holds
+ 	      ; registers in SImode.
+ 	      (if (and
+ 		   (rtx-operand? (rtx-index-of-value regno))
+ 		   (equal?
+ 		    (op:hw-name (rtx-operand-obj (rtx-index-of-value regno)))
+ 		    regname)
+ 
+ 		   ; For the modes specified on reg and the operand,
+ 		   ; only do the simplification when both have the
+ 		   ; same mode, or if either is DFLT, the other one
+ 		   ; having the "natural" mode of the register.
+ 		   ;  We can only check modes of the hardware,
+ 		   ; i.e. (op:mode ), when keeping just one mach, so
+ 		   ; we'll assume we can't make the simplification at
+ 		   ; other times.  One occasion we will be called with
+ 		   ; multiple machs active is when generating
+ 		   ; ARCH-desc.h for the simulator.
+ 		   (not (keep-multiple?))
+ 		   (let ((xmode (rtx-mode (rtx-index-of-value regno)))
+ 			 (natmode (op:mode (rtx-operand-obj
+ 					    (rtx-index-of-value regno)))))
+ 		     (or (mode:eq? regmode xmode)
+ 			 (and (mode:eq? 'DFLT regmode)
+ 			      (mode:eq? natmode xmode))
+ 			 (and (mode:eq? 'DFLT xmode)
+ 			      (mode:eq? natmode regmode)))))
+ 		  (begin
+ 		    (logit 4
+ 			   "REG INDEX-OF: -" (rtx-dump expr) "\n"
+ 			   "REG INDEX-OF: +" (rtx-dump
+ 					      (rtx-index-of-value regno))
+ 			   "\n")
+ 
+ 		    (-rtx-traverse
+ 		     (rtx-index-of-value regno)
+ 		     'RTX 'DFLT expr op-pos tstate appstuff))
+ 		    #f))
+ 
+ 	       ((if)
+ 
+ 		; Transform (reg h-hw RMODE (if COND ntrue nfalse)) into
+ 		; (if RMODE COND (reg h-hw RMODE ntrue)
+ 		;		 (reg h-hw RMODE nfalse))
+ 		; if further simplifications eliminate terms in ntrue
+ 		; and nfalse, as with the index-of case above.
+ 		;  RMODE has to be collected from the natural mode of
+ 		; the register, if it's DFLT in the original
+ 		; expression.  Again, we can only check modes of the
+ 		; hardware, i.e. (op:mode ), when keeping just one
+ 		; mach, so we'll assume we can't make the
+ 		; simplification at other times.
+ 		(if (keep-multiple?)
+ 		    #f
+ 		    (let*
+ 			((regmode (rtx-mode expr))
+ 			 (rmode
+ 			  (if (mode:eq? regmode 'DFLT)
+ 			      (obj:name (hw-mode (current-hw-sem-lookup-1
+ 						  regname)))
+ 			      regmode))
+ 			 (simplified-result
+ 			  (-rtx-traverse
+ 			   (rtx-make
+ 			    'if
+ 			    rmode
+ 			    (rtx-if-test regno)
+ 			    (rtx-make 'reg regmode
+ 				      regname (rtx-if-then regno))
+ 			    (rtx-make 'reg regmode
+ 				      regname (rtx-if-else regno)))
+ 			   'RTX rmode expr op-pos tstate appstuff)))
+ 
+ 		      ; Only pass on the simplification if (at least) the
+ 		      ; reg parts were simplified away.
+ 		      (if (or (not (rtx-kind? 'if simplified-result))
+ 			      (and (not (rtx-kind? 'reg (rtx-if-then
+ 							 simplified-result)))
+ 				   (not (rtx-kind? 'reg (rtx-if-then
+ 							 simplified-result)))))
+ 			  (begin
+ 			    (logit 4
+ 				   "REG-IF -: " (rtx-dump expr) "\n"
+ 				   "REG-IF +: " (rtx-dump simplified-result)
+ 				   "\n")
+ 			    simplified-result)
+ 			  #f))))
+ 	       (else #f)))
+ 	 #f))
+ 
      ; Leave EXPR unchanged and continue.
      (else #f))
  )

brgds, H-P

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFA:] Simplification transformations in semantics.scm
  2002-12-06 19:54 [RFA:] Simplification transformations in semantics.scm Hans-Peter Nilsson
@ 2002-12-06 20:29 ` Hans-Peter Nilsson
  2002-12-06 21:26 ` Doug Evans
  2002-12-13  6:10 ` Doug Evans
  2 siblings, 0 replies; 8+ messages in thread
From: Hans-Peter Nilsson @ 2002-12-06 20:29 UTC (permalink / raw)
  To: cgen

> Date: Sat, 7 Dec 2002 04:54:00 +0100
> From: Hans-Peter Nilsson <hp@axis.com>

> 	* semantics.scm (-simplify-expr-fn) <set, set-quiet, reg>: New
> 	simplifications.

I forgot to mention that this patch causes no changes to files
in binutils and sim marked "THIS FILE IS MACHINE GENERATED WITH
CGEN" for i960, m32r and xstormy16, when regenerated.  As
before, I'd like to hear about what'd be considered suitable
test coverage for a patch like this.

brgds, H-P

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [RFA:] Simplification transformations in semantics.scm
  2002-12-06 19:54 [RFA:] Simplification transformations in semantics.scm Hans-Peter Nilsson
  2002-12-06 20:29 ` Hans-Peter Nilsson
@ 2002-12-06 21:26 ` Doug Evans
  2002-12-13 21:44   ` Hans-Peter Nilsson
  2002-12-13  6:10 ` Doug Evans
  2 siblings, 1 reply; 8+ messages in thread
From: Doug Evans @ 2002-12-06 21:26 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: cgen

I'd like to have the .cpu file that this is necessary for
so that I can play with it a bit first.  Possible?

IIRC, I decided (either explicitly or otherwise) to not allow
conditionals in the left hand side of an assignment.
It complicates things a lot.
I believe gcc doesn't support them (does it?)
and in general I'm always leary of introducing radical
departures from gcc rtl without a lot of thought and compelling
arguments that it is warranted.

Hans-Peter Nilsson writes:
 > These simplifications make the CGEN semantic compilation see
 > somewhat-trivial sets of registers such that the "profile"
 > support (actually: model unit machinery) marks the right operand
 > for input and output.  In a .cpu file I have, I use (through
 > some levels of pmacros) (set (reg h-hw (index-of (operand op))) src)
 > and the other forms below, which confuse CGEN.
 > 
 > Another way (independently correct AFAICT) to make model support
 > work for me would be to make the model machinery just ignore the
 > semantics of the insn and use the operands I *tell it* to use in
 > the model description, as long as it can find them in the format
 > description.  Right now inputs and outputs of units are filtered
 > through whatever is collected from the semantic compilation, so
 > "op" in (set (reg h-hw (index-of (operand op))) src) is *not*
 > marked as an output operand.  Subsequently, with (op INT -1) in
 > a unit output list, the model function for that unit always get
 > -1 for that operand; op is listed as an input but not as an
 > output.  Gah!  That's a bug, I think; the unit input and output
 > should override what the semantic compiler thinks.

I don't understand.  There's some missing info here.
At face value `op' is not an output operand.
Maybe if I saw the entire define-insn it would be more clear.
Howzaboutit?

 > In summary, this patch simplifies (as the comments say):
 > 
 > (reg XMODE h-hw (index-of YMODE (operand XMODE op)))
 >  into
 > (operand XMODE op)))
 > 
 > (SET (if IFMODE COND ltrue lfalse) src)
 >  into (for SET = {set, set-quiet}):
 > (if COND (SET ltrue dst) (SET lfalse dst))
 > 
 > (reg h-hw RMODE (if COND ntrue nfalse))
 >  into
 > (if RMODE COND (reg h-hw RMODE ntrue)
 > 	       (reg h-hw RMODE nfalse))
 >  but only if simplification makes that latter expression
 >  not take that form, i.e. (if COND (reg...) (reg...))
 > 
 > If you accept this change but consider it so large that
 > copyright is an issue, we have to work something out, since
 > there's no copyright agreement between Axis Communications and
 > Red Hat.  Suggestions welcome.  FWIW, I can only think of this
 > way to accomplish what I describe above, so I hope to get away
 > with it as obvious enough.  (I wish, I wish, that Red Hat would
 > find a way to assign copyright for CGEN to the FSF.  Oh yes, and
 > peace of earth.)
 > 
 > 	* semantics.scm (-simplify-expr-fn) <set, set-quiet, reg>: New
 > 	simplifications.
 > 
 > Index: semantics.scm
 > ===================================================================
 > RCS file: /cvs/src/src/cgen/semantics.scm,v
 > retrieving revision 1.1.1.1
 > diff -c -p -r1.1.1.1 semantics.scm
 > *** semantics.scm	28 Jul 2000 04:11:52 -0000	1.1.1.1
 > --- semantics.scm	7 Dec 2002 02:48:45 -0000
 > ***************
 > *** 256,261 ****
 > --- 256,392 ----
 >   	   known-val ; (rtx-make 'const 'INT known-val)
 >   	   #f)))
 >   
 > +     ((set set-quiet)
 > +      ; Transform: (set (if IFMODE COND ltrue lfalse) src)
 > +      ; into: (if COND (set ltrue dst) (set lfalse dst))
 > +      ; hoping for further simplification through the
 > +      ; regno-operand-to-operand simplification below.
 > +      ; This conditional-lvalue destination is expected from the
 > +      ; if-transformations below rather than from user input. 
 > +      ; FIXME: Other conditionals than "if" may be useful
 > +      ; too.  Add them as the need arises.  Maybe check src for 'if too.
 > +      (let ((ifexpr (-rtx-traverse (rtx-set-dest expr)
 > + 				    'RTX 'DFLT expr 2 tstate appstuff))
 > + 	     (src (-rtx-traverse (rtx-set-src expr)
 > + 					'RTX 'DFLT expr 3 tstate appstuff)))
 > + 	 (if (rtx-kind? 'if ifexpr)
 > + 	     (let* ((name (rtx-name expr))
 > + 		    (simplified-result
 > + 		     (rtx-make
 > + 		      'if 'DFLT (rtx-if-test ifexpr)
 > + 		      (rtx-make name
 > + 				(rtx-if-then ifexpr) src)
 > + 		      (rtx-make name
 > + 				(rtx-if-else ifexpr) src))))
 > + 	       (logit 4
 > + 		      "SET -: " (rtx-dump expr) "\n"
 > + 		      "SET +: " (rtx-dump simplified-result) "\n")
 > + 	       simplified-result)
 > + 	     #f)))
 > + 
 > +     ((reg)
 > +      (if (rtx-reg-number expr)
 > + 	 (let* ((regname (rtx-reg-name expr))
 > + 		(regmode (rtx-mode expr))
 > + 		(regno (-rtx-traverse (rtx-reg-number expr)
 > + 				      'RTX 'DFLT expr 3 tstate appstuff)))
 > + 	   (case (rtx-name regno)
 > + 	     ((index-of)
 > + 
 > + 	      ; When op is a h-hw, simplify
 > + 	      ; (reg XMODE h-hw (index-of YMODE (operand XMODE op)))
 > + 	      ; into (operand XMODE op).  For example, (reg h-gr
 > + 	      ; (regno Rd)) into Rd, when Rd is a h-gr and likewise
 > + 	      ; (reg SI h-gr (regno Rd)) provided that h-gr holds
 > + 	      ; registers in SImode.
 > + 	      (if (and
 > + 		   (rtx-operand? (rtx-index-of-value regno))
 > + 		   (equal?
 > + 		    (op:hw-name (rtx-operand-obj (rtx-index-of-value regno)))
 > + 		    regname)
 > + 
 > + 		   ; For the modes specified on reg and the operand,
 > + 		   ; only do the simplification when both have the
 > + 		   ; same mode, or if either is DFLT, the other one
 > + 		   ; having the "natural" mode of the register.
 > + 		   ;  We can only check modes of the hardware,
 > + 		   ; i.e. (op:mode ), when keeping just one mach, so
 > + 		   ; we'll assume we can't make the simplification at
 > + 		   ; other times.  One occasion we will be called with
 > + 		   ; multiple machs active is when generating
 > + 		   ; ARCH-desc.h for the simulator.
 > + 		   (not (keep-multiple?))
 > + 		   (let ((xmode (rtx-mode (rtx-index-of-value regno)))
 > + 			 (natmode (op:mode (rtx-operand-obj
 > + 					    (rtx-index-of-value regno)))))
 > + 		     (or (mode:eq? regmode xmode)
 > + 			 (and (mode:eq? 'DFLT regmode)
 > + 			      (mode:eq? natmode xmode))
 > + 			 (and (mode:eq? 'DFLT xmode)
 > + 			      (mode:eq? natmode regmode)))))
 > + 		  (begin
 > + 		    (logit 4
 > + 			   "REG INDEX-OF: -" (rtx-dump expr) "\n"
 > + 			   "REG INDEX-OF: +" (rtx-dump
 > + 					      (rtx-index-of-value regno))
 > + 			   "\n")
 > + 
 > + 		    (-rtx-traverse
 > + 		     (rtx-index-of-value regno)
 > + 		     'RTX 'DFLT expr op-pos tstate appstuff))
 > + 		    #f))
 > + 
 > + 	       ((if)
 > + 
 > + 		; Transform (reg h-hw RMODE (if COND ntrue nfalse)) into
 > + 		; (if RMODE COND (reg h-hw RMODE ntrue)
 > + 		;		 (reg h-hw RMODE nfalse))
 > + 		; if further simplifications eliminate terms in ntrue
 > + 		; and nfalse, as with the index-of case above.
 > + 		;  RMODE has to be collected from the natural mode of
 > + 		; the register, if it's DFLT in the original
 > + 		; expression.  Again, we can only check modes of the
 > + 		; hardware, i.e. (op:mode ), when keeping just one
 > + 		; mach, so we'll assume we can't make the
 > + 		; simplification at other times.
 > + 		(if (keep-multiple?)
 > + 		    #f
 > + 		    (let*
 > + 			((regmode (rtx-mode expr))
 > + 			 (rmode
 > + 			  (if (mode:eq? regmode 'DFLT)
 > + 			      (obj:name (hw-mode (current-hw-sem-lookup-1
 > + 						  regname)))
 > + 			      regmode))
 > + 			 (simplified-result
 > + 			  (-rtx-traverse
 > + 			   (rtx-make
 > + 			    'if
 > + 			    rmode
 > + 			    (rtx-if-test regno)
 > + 			    (rtx-make 'reg regmode
 > + 				      regname (rtx-if-then regno))
 > + 			    (rtx-make 'reg regmode
 > + 				      regname (rtx-if-else regno)))
 > + 			   'RTX rmode expr op-pos tstate appstuff)))
 > + 
 > + 		      ; Only pass on the simplification if (at least) the
 > + 		      ; reg parts were simplified away.
 > + 		      (if (or (not (rtx-kind? 'if simplified-result))
 > + 			      (and (not (rtx-kind? 'reg (rtx-if-then
 > + 							 simplified-result)))
 > + 				   (not (rtx-kind? 'reg (rtx-if-then
 > + 							 simplified-result)))))
 > + 			  (begin
 > + 			    (logit 4
 > + 				   "REG-IF -: " (rtx-dump expr) "\n"
 > + 				   "REG-IF +: " (rtx-dump simplified-result)
 > + 				   "\n")
 > + 			    simplified-result)
 > + 			  #f))))
 > + 	       (else #f)))
 > + 	 #f))
 > + 
 >       ; Leave EXPR unchanged and continue.
 >       (else #f))
 >   )
 > 
 > brgds, H-P
 > 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [RFA:] Simplification transformations in semantics.scm
  2002-12-06 19:54 [RFA:] Simplification transformations in semantics.scm Hans-Peter Nilsson
  2002-12-06 20:29 ` Hans-Peter Nilsson
  2002-12-06 21:26 ` Doug Evans
@ 2002-12-13  6:10 ` Doug Evans
  2002-12-13  6:56   ` Hans-Peter Nilsson
  2 siblings, 1 reply; 8+ messages in thread
From: Doug Evans @ 2002-12-13  6:10 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: cgen

Hans-Peter Nilsson writes:
 > Another way (independently correct AFAICT) to make model support
 > work for me would be to make the model machinery just ignore the
 > semantics of the insn and use the operands I *tell it* to use in
 > the model description, as long as it can find them in the format
 > description.  Right now inputs and outputs of units are filtered
 > through whatever is collected from the semantic compilation, so
 > "op" in (set (reg h-hw (index-of (operand op))) src) is *not*
 > marked as an output operand.  Subsequently, with (op INT -1) in
 > a unit output list, the model function for that unit always get
 > -1 for that operand; op is listed as an input but not as an
 > output.  Gah!  That's a bug, I think; the unit input and output
 > should override what the semantic compiler thinks.

One way to solve this which I thought I implemented (but now can't
find it) is something along these lines.

Suppose you could give names to expressions in the semantic code
and use these names in the model description.
Note that I don't think you want to use the format description
as some operands can be implicit.

e.g. something like

;[sr,dr are operands]

(dni add-gr-13
  ...
  (sequence ((QI tmp))
    (set tmp (rename QI foo (reg QI h-gr 13)))
    (set dr (add tmp sr)))
  ((model-baz (unit u-exec (in src1 sr) (in src2 foo) (out dr #f))))
)

Here `rename' is being used to attach a name to something that is then
referenced by the model parameters of the dni.

semantic operand sr -> u-exec input src1
semantic operand foo -> u-exec input src2
semantic operand dr -> u-exec output dr

[The `tmp' is unnecessary of course.]

I _think_ this will be very easy to implement and very flexible.
Thoughts?

 > In summary, this patch simplifies (as the comments say):
 > 
 > (reg XMODE h-hw (index-of YMODE (operand XMODE op)))
 >  into
 > (operand XMODE op)))
 > 
 > (SET (if IFMODE COND ltrue lfalse) src)
 >  into (for SET = {set, set-quiet}):
 > (if COND (SET ltrue dst) (SET lfalse dst))
 > 
 > (reg h-hw RMODE (if COND ntrue nfalse))
 >  into
 > (if RMODE COND (reg h-hw RMODE ntrue)
 > 	       (reg h-hw RMODE nfalse))
 >  but only if simplification makes that latter expression
 >  not take that form, i.e. (if COND (reg...) (reg...))

How much pain would it be if we continue to disallow
conditions in the left side of `set'?
I don't mind adding something that let's one write such
conditions as long as they get removed before the rtl parser sees them.
By that I mean above the rtl language we can play some games,
but at the level of the rtl language, conditions in the left side
of `set' do not exist.  E.g. maybe a special form or macro
that makes things look "as if" there's a condition present.
I think it's more or less what you already have, except I want
the transformations to live above the rtl language line, not below it.
Sound reasonable?


[ok, now I'm off to get some sleep ...]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFA:] Simplification transformations in semantics.scm
  2002-12-13  6:10 ` Doug Evans
@ 2002-12-13  6:56   ` Hans-Peter Nilsson
  2002-12-13 16:52     ` Doug Evans
  0 siblings, 1 reply; 8+ messages in thread
From: Hans-Peter Nilsson @ 2002-12-13  6:56 UTC (permalink / raw)
  To: dje; +Cc: hans-peter.nilsson, cgen

> From: Doug Evans <dje@transmeta.com>
> Date: Fri, 13 Dec 2002 06:10:14 -0800 (PST)

> Suppose you could give names to expressions in the semantic code
> and use these names in the model description.

That'd be very nice!

> Note that I don't think you want to use the format description
> as some operands can be implicit.

No; currently I don't see how they can be implicit.  It'd be
nice if they could.

> e.g. something like
> 
> ;[sr,dr are operands]
> 
> (dni add-gr-13
>   ...
>   (sequence ((QI tmp))
>     (set tmp (rename QI foo (reg QI h-gr 13)))
>     (set dr (add tmp sr)))
>   ((model-baz (unit u-exec (in src1 sr) (in src2 foo) (out dr #f))))
> )
> 
> Here `rename' is being used to attach a name to something that is then
> referenced by the model parameters of the dni.
> 
> semantic operand sr -> u-exec input src1
> semantic operand foo -> u-exec input src2
> semantic operand dr -> u-exec output dr
>
> [The `tmp' is unnecessary of course.]
> 
> I _think_ this will be very easy to implement and very flexible.
> Thoughts?

The syntax is at first slightly confusing, but it looks fine
otherwise.  Not currently possible *generally* of course; you
can't feed (rename QI foo (add QI sr dr)) to the model
machinery.  It has to be something that maps to one ifield
AFAICT.

>  > (SET (if IFMODE COND ltrue lfalse) src)
>  >  into (for SET = {set, set-quiet}):
>  > (if COND (SET ltrue dst) (SET lfalse dst))

This one above was not intended for user code, just for internal
simplification from the following:

>  > (reg h-hw RMODE (if COND ntrue nfalse))
>  >  into
>  > (if RMODE COND (reg h-hw RMODE ntrue)
>  > 	       (reg h-hw RMODE nfalse))
>  >  but only if simplification makes that latter expression
>  >  not take that form, i.e. (if COND (reg...) (reg...))
> 
> How much pain would it be if we continue to disallow
> conditions in the left side of `set'?

If you mean in (set (reg h-hw RMODE exp1) exp2)
then much so, but in (set exp1 exp2) none at all.  I think it's
currently invalid and should remain so.

> I don't mind adding something that let's one write such
> conditions as long as they get removed before the rtl parser sees them.

Agreed.

> By that I mean above the rtl language we can play some games,
> but at the level of the rtl language, conditions in the left side
> of `set' do not exist.  E.g. maybe a special form or macro
> that makes things look "as if" there's a condition present.
> I think it's more or less what you already have, except I want
> the transformations to live above the rtl language line, not below it.
> Sound reasonable?

Yes!  That was exactly my intention, and what I originally had,
except it looked too non-linear.  I'll cook up a patch to do
that.

> [ok, now I'm off to get some sleep ...]

Sweet dreams!

brgds, H-P

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFA:] Simplification transformations in semantics.scm
  2002-12-13  6:56   ` Hans-Peter Nilsson
@ 2002-12-13 16:52     ` Doug Evans
  2002-12-13 17:40       ` Hans-Peter Nilsson
  0 siblings, 1 reply; 8+ messages in thread
From: Doug Evans @ 2002-12-13 16:52 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: cgen

Hans-Peter Nilsson writes:
 > > How much pain would it be if we continue to disallow
 > > conditions in the left side of `set'?
 > 
 > If you mean in (set (reg h-hw RMODE exp1) exp2)
 > then much so, but in (set exp1 exp2) none at all.  I think it's
 > currently invalid and should remain so.

Righto.  I _think_ (set (reg h-hw RMODE exp1) exp2) may be ok.
exp1 may have conditions but some register of h-hw will be set.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFA:] Simplification transformations in semantics.scm
  2002-12-13 16:52     ` Doug Evans
@ 2002-12-13 17:40       ` Hans-Peter Nilsson
  0 siblings, 0 replies; 8+ messages in thread
From: Hans-Peter Nilsson @ 2002-12-13 17:40 UTC (permalink / raw)
  To: dje; +Cc: hans-peter.nilsson, cgen

> From: Doug Evans <dje@transmeta.com>
> Date: Fri, 13 Dec 2002 16:52:46 -0800 (PST)

> Hans-Peter Nilsson writes:
>  > > How much pain would it be if we continue to disallow
>  > > conditions in the left side of `set'?
>  > 
>  > If you mean in (set (reg h-hw RMODE exp1) exp2)
>  > then much so, but in (set exp1 exp2) none at all.  I think it's
>  > currently invalid and should remain so.
> 
> Righto.  I _think_ (set (reg h-hw RMODE exp1) exp2) may be ok.

(given exp1 a condition, like (if SI ...))

Yes, it definitely is!

brgds, H-P

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFA:] Simplification transformations in semantics.scm
  2002-12-06 21:26 ` Doug Evans
@ 2002-12-13 21:44   ` Hans-Peter Nilsson
  0 siblings, 0 replies; 8+ messages in thread
From: Hans-Peter Nilsson @ 2002-12-13 21:44 UTC (permalink / raw)
  To: dje; +Cc: hans-peter.nilsson, cgen

Going back to some questions I didn't answer.  Maybe they're no
issue now, but anyway, I feel better tying those threads.

> From: Doug Evans <dje@transmeta.com>
> Date: Fri, 6 Dec 2002 21:26:31 -0800 (PST)

> I'd like to have the .cpu file that this is necessary for

(necessary only for the model stuff, that is; not for pure
semantics)

> so that I can play with it a bit first.  Possible?

No sorry.  In due time (deliberately unspecified) though.

> IIRC, I decided (either explicitly or otherwise) to not allow
> conditionals in the left hand side of an assignment.
> It complicates things a lot.
> I believe gcc doesn't support them (does it?)

No, I *think* those would be too complicated to appear without a
.md pattern generating a pattern of that form in the first
place.  I haven't played with it enough to give a conclusive
answer, though.

> Hans-Peter Nilsson writes:
>  > Another way (independently correct AFAICT) to make model support
>  > work for me would be to make the model machinery just ignore the
>  > semantics of the insn and use the operands I *tell it* to use in
>  > the model description, as long as it can find them in the format
>  > description.  Right now inputs and outputs of units are filtered
>  > through whatever is collected from the semantic compilation, so
>  > "op" in (set (reg h-hw (index-of (operand op))) src) is *not*
>  > marked as an output operand.  Subsequently, with (op INT -1) in
>  > a unit output list, the model function for that unit always get
>  > -1 for that operand; op is listed as an input but not as an
>  > output.  Gah!  That's a bug, I think; the unit input and output
>  > should override what the semantic compiler thinks.
> 
> I don't understand.  There's some missing info here.

From your later email I think you understand.  (Right?  Above, I
might certainly have been a bit too terse for usefulness -- it
was a side-track not immediately related to the patch in that
mail.)

> At face value `op' is not an output operand.

Um, no I think it is, provided it's in h-hw.  Agree?

> Maybe if I saw the entire define-insn it would be more clear.
> Howzaboutit?

I'm quite sure you now understand what I had in mind, but
anyway, here's that m32r div insn (trivially) further abused:

Index: m32r.cpu
===================================================================
RCS file: /cvs/src/src/cgen/cpu/m32r.cpu,v
retrieving revision 1.1
diff -c -p -u -p -r1.1 m32r.cpu
cvs server: conflicting specifications of output style
--- m32r.cpu	5 Jul 2001 12:45:47 -0000	1.1
+++ m32r.cpu	14 Dec 2002 05:35:33 -0000
@@ -1026,7 +1026,7 @@
      ()
      "div $dr,$sr"
      (+ OP1_9 OP2_0 dr sr (f-simm16 0))
-     (if (ne sr (const 0)) (set dr (div dr sr)))
+     (if (ne sr (const 0)) (set (reg WI h-gr (regno dr)) (div dr sr)))
      ((m32r/d (unit u-exec (cycles 37)))
       (m32rx (unit u-exec (cycles 37))))
 )

For the conditional-regno variant, replace (regno dr) with e.g.
(if SI (eq sr 0) (regno dr) 1).

brgds, H-P

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-12-14  5:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-06 19:54 [RFA:] Simplification transformations in semantics.scm Hans-Peter Nilsson
2002-12-06 20:29 ` Hans-Peter Nilsson
2002-12-06 21:26 ` Doug Evans
2002-12-13 21:44   ` Hans-Peter Nilsson
2002-12-13  6:10 ` Doug Evans
2002-12-13  6:56   ` Hans-Peter Nilsson
2002-12-13 16:52     ` Doug Evans
2002-12-13 17:40       ` Hans-Peter Nilsson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).