[RFA:] Simplification transformations in semantics.scm

[Doug Evans <dje at transmeta dot com>]

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 ...]