This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: [RFA:] Simplification transformations in semantics.scm
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: dje at transmeta dot com
- Cc: hans-peter dot nilsson at axis dot com, cgen at sources dot redhat dot com
- Date: Fri, 13 Dec 2002 15:56:02 +0100
- Subject: Re: [RFA:] Simplification transformations in semantics.scm
> 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