From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11990 invoked by alias); 14 Dec 2002 00:50:49 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 11983 invoked from network); 14 Dec 2002 00:50:45 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 14 Dec 2002 00:50:45 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id QAA18861; Fri, 13 Dec 2002 16:50:40 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma018829; Fri, 13 Dec 02 16:50:22 -0800 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBE0oQR00424; Fri, 13 Dec 2002 16:50:26 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id QAA20568; Fri, 13 Dec 2002 16:50:25 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15866.32849.125398.731160@casey.transmeta.com> Date: Fri, 13 Dec 2002 16:50:00 -0000 To: Hans-Peter Nilsson Cc: cgen@sources.redhat.com Subject: Re: [RFA:] In -build-operand!, -build-reg-operand, collect the natural mode, not the used mode, In-Reply-To: <200212131442.gBDEgHeR030568@ignucius.axis.se> References: <15865.58703.575946.279017@xris-athlon.transmeta.com> <200212131442.gBDEgHeR030568@ignucius.axis.se> X-SW-Source: 2002-q4/txt/msg00087.txt.bz2 Hans-Peter Nilsson writes: > > Note also that while there are two copies of in_h_gr_, > > 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_. > > 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.