[M3devel] a trouble with passing records by value..

[Jay K]

Both the frontend and backend seem to layout types. This is bad.
I know we pass sizes/alignments to the backend, but to what extent does it have its own notions and make its own decisions?
  I don't fully know.
It is ok if they agree, but they absolutely must agree.
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.
 
 
But what about e.g. the overall size of a record?
We don't specify the layout of stack frames I believe.
 Perhaps we should? Perhaps every function should have one "big" local record that contains its locals?
  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.
 
 
There is I believe a real mismatch between the frontend and backend.
I'm wondering if my feeding any type information to the backend is such a good idea afterall.
It provides wonderful improvements to debugging, but feeds into this "conflict".
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.
 
 
Just then a matter of dealing with records by value in a way that works.
 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Tue, 31 Aug 2010 20:59:09 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] a trouble with passing records by value..
> 
> On 31 Aug 2010, at 19:13, Jay K wrote:
> 
> > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types.
> > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation.
> 
> Why would it not? We specify alignment...
> 
> > It might also be good to have the backend feed its computed sizes/alignments back to the front end.
> > It'd be via more files.
> 
> YUCK!!!!!!!!! Not a good plan...
> 
> > 
> > - Jay
> > 
> > ----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: hosking at cs.purdue.edu
> >> Date: Tue, 31 Aug 2010 23:09:56 +0000
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] a trouble with passing records by value..
> >> 
> >> 
> >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.
> >> Yucky.
> >> 
> >> I'm also going to try giving temporaries types.
> >> Another m3cg change like pop_struct.
> >> Given the latest internal error I saw.
> >> Maybe review m3cg for more missing type information.
> >> 
> >> - Jay
> >> 
> >> ----------------------------------------
> >>> From: jay.krell at cornell.edu
> >>> To: hosking at cs.purdue.edu
> >>> CC: m3devel at elegosoft.com
> >>> Subject: RE: [M3devel] a trouble with passing records by value..
> >>> Date: Tue, 31 Aug 2010 23:05:08 +0000
> >>> 
> >>> 
> >>> t1 must still be passed in registers. The ABI can't be changed by that.
> >>> 
> >>> - Jay
> >>> 
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] a trouble with passing records by value..
> >>>> 
> >>>> What happens if you take the address of t inside ActionLookup?
> >>>> What happens if you take the address of t1 inside main?
> >>>> 
> >>>> On 31 Aug 2010, at 07:25, Jay K wrote:
> >>>> 
> >>>>> 
> >>>>> Given something like this:
> >>>>> 
> >>>>> jbook2:p247 jay$ more 1.c
> >>>>> #include
> >>>>> 
> >>>>> typedef struct { long code; long value; } T1;
> >>>>> 
> >>>>> void ActionLookup(T1 t, long code, long value);
> >>>>> 
> >>>>> void ActionLookup(T1 t, long code, long value)
> >>>>> {
> >>>>> assert(t.code == code);
> >>>>> assert(t.value == value);
> >>>>> }
> >>>>> 
> >>>>> int main()
> >>>>> {
> >>>>> T1 t1 = {2,2};
> >>>>> ActionLookup(t1, 2, 2);
> >>>>> return 0;
> >>>>> }
> >>>>> j
> >>>>> 
> >>>>> 
> >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good.
> >>>>> 
> >>>>> 
> >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value,
> >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is,
> >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers.
> >>>>> Darn.
> >>>>> 
> >>>>> 
> >>>>> If m3cg were higher level this could be better.
> >>>>> 
> >>>>> 
> >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed"
> >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers.
> >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying?
> >>>>> 
> >>>>> 
> >>>>> Maybe we should have M3CG include field references?
> >>>>> 
> >>>>> 
> >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the
> >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator.
> >>>>> 
> >>>>> 
> >>>>> - Jay
> >>>>> 
> >>>> 
> >>> 
> >> 
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100901/67e96434/attachment-0002.html>