<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Both the frontend and backend seem to layout types. This is bad.<BR>
I know we pass sizes/alignments to the backend, but to what extent does it have its own notions and make its own decisions?<BR>
I don't fully know.<BR>
It is ok if they agree, but they absolutely must agree.<BR>
I suppose it is much less bad, and maybe they can disagree, because we never access fields, from the backend's point of view -- so it doesn't matter much if it thinks they are elsewhere.<BR>
<BR>
<BR>
But what about e.g. the overall size of a record?<BR>
We don't specify the layout of stack frames I believe.<BR>
Perhaps we should? Perhaps every function should have one "big" local record that contains its locals?<BR>
This will lead to increase correctness by decreased mismatch between backend and frontend, but it would also tie the optimizer's hand a bunch, e.g. no "stack packing" (placing locals in the same location if their lifetimes don't overlap), no removal of unused locals.<BR>
<BR>
<BR>
There is I believe a real mismatch between the frontend and backend.<BR>
I'm wondering if my feeding any type information to the backend is such a good idea afterall.<BR>
It provides wonderful improvements to debugging, but feeds into this "conflict".<BR>
If we only tell the backend we just have blocks of sizes/alignments, and we add offsets to those blocks, cast, deref, we will continue to avoid, e.g. backend record layout mattering.<BR>
<BR>
<BR>
Just then a matter of dealing with records by value in a way that works.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>
> From: hosking@cs.purdue.edu<BR>> Date: Tue, 31 Aug 2010 20:59:09 -0400<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> <BR>> On 31 Aug 2010, at 19:13, Jay K wrote:<BR>> <BR>> > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types.<BR>> > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation.<BR>> <BR>> Why would it not? We specify alignment...<BR>> <BR>> > It might also be good to have the backend feed its computed sizes/alignments back to the front end.<BR>> > It'd be via more files.<BR>> <BR>> YUCK!!!!!!!!! Not a good plan...<BR>> <BR>> > <BR>> > - Jay<BR>> > <BR>> > ----------------------------------------<BR>> >> From: jay.krell@cornell.edu<BR>> >> To: hosking@cs.purdue.edu<BR>> >> Date: Tue, 31 Aug 2010 23:09:56 +0000<BR>> >> CC: m3devel@elegosoft.com<BR>> >> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> >> <BR>> >> <BR>> >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.<BR>> >> Yucky.<BR>> >> <BR>> >> I'm also going to try giving temporaries types.<BR>> >> Another m3cg change like pop_struct.<BR>> >> Given the latest internal error I saw.<BR>> >> Maybe review m3cg for more missing type information.<BR>> >> <BR>> >> - Jay<BR>> >> <BR>> >> ----------------------------------------<BR>> >>> From: jay.krell@cornell.edu<BR>> >>> To: hosking@cs.purdue.edu<BR>> >>> CC: m3devel@elegosoft.com<BR>> >>> Subject: RE: [M3devel] a trouble with passing records by value..<BR>> >>> Date: Tue, 31 Aug 2010 23:05:08 +0000<BR>> >>> <BR>> >>> <BR>> >>> t1 must still be passed in registers. The ABI can't be changed by that.<BR>> >>> <BR>> >>> - Jay<BR>> >>> <BR>> >>> ----------------------------------------<BR>> >>>> From: hosking@cs.purdue.edu<BR>> >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400<BR>> >>>> To: jay.krell@cornell.edu<BR>> >>>> CC: m3devel@elegosoft.com<BR>> >>>> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> >>>> <BR>> >>>> What happens if you take the address of t inside ActionLookup?<BR>> >>>> What happens if you take the address of t1 inside main?<BR>> >>>> <BR>> >>>> On 31 Aug 2010, at 07:25, Jay K wrote:<BR>> >>>> <BR>> >>>>> <BR>> >>>>> Given something like this:<BR>> >>>>> <BR>> >>>>> jbook2:p247 jay$ more 1.c<BR>> >>>>> #include<BR>> >>>>> <BR>> >>>>> typedef struct { long code; long value; } T1;<BR>> >>>>> <BR>> >>>>> void ActionLookup(T1 t, long code, long value);<BR>> >>>>> <BR>> >>>>> void ActionLookup(T1 t, long code, long value)<BR>> >>>>> {<BR>> >>>>> assert(t.code == code);<BR>> >>>>> assert(t.value == value);<BR>> >>>>> }<BR>> >>>>> <BR>> >>>>> int main()<BR>> >>>>> {<BR>> >>>>> T1 t1 = {2,2};<BR>> >>>>> ActionLookup(t1, 2, 2);<BR>> >>>>> return 0;<BR>> >>>>> }<BR>> >>>>> j<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good.<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value,<BR>> >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is,<BR>> >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers.<BR>> >>>>> Darn.<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> If m3cg were higher level this could be better.<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed"<BR>> >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers.<BR>> >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying?<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> Maybe we should have M3CG include field references?<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the<BR>> >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator.<BR>> >>>>> <BR>> >>>>> <BR>> >>>>> - Jay<BR>> >>>>> <BR>> >>>> <BR>> >>> <BR>> >> <BR>> > <BR>> <BR> </body>
</html>