Re: [RFA:] Simplification transformations in semantics.scm

[Hans-Peter Nilsson <hans-peter.nilsson@axis.com>]

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