Re: [RFA:] In -build-operand!, -build-reg-operand, collect the natural mode, not the used mode,

[Doug Evans <dje@transmeta.com>]

Hans-Peter Nilsson writes:
 > > Note also that while there are two copies of in_h_gr_<mumble>,
 > > there's no problem with them as the mode distinguishes them.
 > 
 > Sorry, I think you're missing the point: I want to get the
 > register accesses through to the model machinery.

Righto.
My point was solely focused on the compilation error.
Clearly we want to be able to feed explicitly specified
registers into the model machinery.

 > > Clearly that's what's already happening with in_h_gr_<mumble>.
 > > No claim is also made that this is a better way to look at the bug.
 > > Maybe it is, maybe it isn't.  It comes down to "what do we want?".
 > 
 > No no no.  Not a copy for each accessed mode, please.  Please
 > don't do that.  For one, how would you map that on the model
 > machinery?  How you you send this to the unit function in:
 > 
 >     (unit u-foo "Foo Unit" () 1 1 ()
 >           ((dr INT -1))
 >           () ()))
 > 
 > Consider the case where one insn accesses a register in multiple
 > modes, while another accesses it in one mode.

I recognize the issue.

But suppose each of those multiple-mode accesses feed into different
units and suppose they're conditionally referenced.  Collapsing
them all into one would be wrong.
The proposed new `rename' rtx would help here, each relevant reference
that needs to be fed into a model would be given a special name and
that name would be used to plug that operand into the model units.
No claim is made that it is the best solution for this particular case,
but it seems reasonable.

 > > We should also look at the effect on opcodes/m32r-opinst.c.
 > > The salient change here is:
 > > 
 > > @@ -202,6 +202,16 @@ static const CGEN_OPINST sfmt_cmpz_ops[]
 > 
 > > Is the mode relevant here?  What do you think?
 > 
 > I don't claim to know my way around the CGEN assembler/opcode
 > parts, except as I told previously, that the assembler parts
 > should obviously *not* be affected by anything in the semantics.
 > It should only look at the (+ OP1_9 OP2_0 dr sr (f-simm16 0))
 > (heh, cute, looks like a curse :-) format line.

I don't want opcodes/* to be treated as solely assembler/opcode parts.
For example, suppose one has a fairly big and complicated program
and verifying its correctness is critical.  One would wish to employ
lots of different kinds of verification tools.  One tool one could employ
would be a static program analysis tool.  Crack open each instruction in the
compiled form of the program, build a flow graph, and analyze away.
I'd like to bring opcodes/* to a point where it would form the basis
for such a tool (among many other things).

 > > where there's no current mode one can apply to eax,ebx,etc. and get the
 > > intended meaning.  So do we outlaw such things and say
 > > registers can only be set in their natural mode, and for x86,m68k,etc.
 > > we create additional registers that alias the appropriate bits of the
 > > "real" register?
 > 
 > Does the patch have this "outlawing" effect?  I didn't intend
 > that.

No, nothing outlawed.  Just trying to spur some creative juices.
Fermented grape juice, mmmm....

 > >  Or do we attach meaning to setting a register in
 > > a mode different than its natural mode?
 > 
 > Like what? (Except for the obvious: affecting only the part of
 > the register corresponding to the mode.  I did not intend to
 > change this.)

Just the obvious.   I was thinking out loud about the possibility
of applying your patch and seeing where it leads.  What if we make the
design choice of saying "mode is irrelevant", and all objects are _only_
accessed in their natural mode (except for memory of course),
treating reading and writing of objects equivalently.
It is an appealing simplification, but there are no free lunches.
gcc doesn't have different register numbers for %eax vs %ax vs %al
for good reasons.
[note: for memory, often byte enables are more useful than mode
anyways, so even for memory maybe we don't want modes.  Of course,
we could create a mode for each possible byte enable combination.
Muhahaha! :-)]

This would mean, for example, that one couldn't have "(set QI eax 42)"
mean "(set QI al 42)" in x86.  To accomplish this one would have to
create a set of register arrays for each of the ways eax,ebx,etc.
can be accessed.  I'm not sure we want to go there.

 > > [for x86 and ah,bh,etc. we can still go the latter way and either
 > > create new modes (blech (*1)) or define aliases]
 > 
 > No new modes or aliases, please.

Righto.  Here was just (trying to) state all the possibilities that
came to mind, regardless of their merit.

 > > I've started to come up with a patch that allows us to retain the mode
 > > of the use, rather than always using the natural mode, should we want to go
 > > this route.  I think we do.
 > 
 > And the model thingy?  That's the one thing that's important to
 > me.

Righto.