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: Sat, 14 Dec 2002 06:44:47 +0100
- Subject: Re: [RFA:] Simplification transformations in semantics.scm
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