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

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> 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