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

Wed Sep 1 06:26:48 CEST 2010

 > I don't particularly understand the SPARC64_SOLARIS issue

When a record is passed by value SPARC64_SOLARIS backend goes to figure
out the ABI for it and it hits an assertion failure.

Historically no type was associated with parameters and locals in the backend.
At least not for records.
Maybe they had a size and an alignment.
But certainly no fields.

You know -- imagine a record with non-zero size but zero fields. Wierd eh?
The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion.
  (gcc can cope with some such cases the comments say, but still..)

If you start but don't finish fixing this problem, by giving types to parameters,
you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets.
I don't fully understand/remember the problem, but it is easy to uncover.

Part of the problem was plain missing type information -- I fixed that in m3front.
If you both imported and defined a type, you wouldn't get the information.
    m3front was deliberately skipping imported types, even if they coincided with locally defined types.
If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now,
if the supertype matches.

That's still not the extent of the problem on AMD64_DARWIN though.

Test case p247 covers much of this.
It just passes a record with a pointer and integer by value.
Two integers (in record) have same problem.

To try to summarize:
   There has been a historical lack of use of type information in the backend. 
   Mostly the backend does get good type information from frontend, but
    it didn't associate it with locals/parameters. And it is better now. 
   (globals are worse still I believe)

   I'm not 100% sure, but it appears to me that both the frontend and backend layout records.
    That is, determine the offset of each field, such as by adding up the sizes of preceding fields.
     (It is more involved than that, due to alignment.)
   I am concerned that these two layouts might not agree, and the result would be terrible.

-  Jay

From: hosking at cs.purdue.edu
Date: Tue, 31 Aug 2010 22:22:16 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] a trouble with passing records by value..

I believe there is one way out here.
Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type.
We can even rely on Modula-3 run-time support to interpret the UIDs.

I don't particularly understand the SPARC64_SOLARIS issue.  Can you elaborate?

On 31 Aug 2010, at 22:00, Jay K wrote:

> I strongly advise against that hack.

It's not my favorite, but I'm possibly in
a jam here between providing type information
for debugging with stock gdb, and I suspect an
overall poor story regarding type information
and backend/frontend interface.

One option is to give up on type information.
i.e. go back to the historical way i.e. before August 2010.
That worked ok as far as most people observed (except for stock gdb..)
However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS.

I suspect we never historically passed records in registers, and that we must continue not to.
  Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if
  it notices their address taken.

It might suffice, besides giving up on type information, to
mark all records as "addressable". Or, again, to slightly
hack the backend. Maybe only for SPARC64.

The bigger controversial question is if we should change
m3cg (the interface) to know about "field references".

And then, again, should layout be done by the frontend, backend,
or both? There are arguments for all three options.
I think the current *design* is frontend only.
But I think the current *implementation* is both (except for NT386).
And probably the right way is backend only.

This would also generally fix the pesky "load/store use bitfields" thing.

Debuggability with stock gdb does seem like a nice idea.
But I see now it might conflict tremendously with our odd structuring.

I'll keep poking at it. e.g.: good type information, including for temporaries,
and mark all record types/values as addressable.

We should still consider the notion of "field references" in the m3cg interface.
 Right? I'm not crazy in the "mismatch" I seem to "detect"?
Probably besides given the field "name", we should pass what the frontend
thinks is the offset, type, alignment. This will serve two purposes.
For NT386, it will let it continue to be fairly typeless, at least for now.
For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed.

I still have to understand how bitfields fit here also.
Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes!

 - Jay

> From: hosking at cs.purdue.edu
> Date: Tue, 31 Aug 2010 20:58:07 -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:09, Jay K wrote:
> 
> > 
> > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.
> > Yucky.
> 
> I strongly advise against that hack.
> 
> > 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.
> 
> This would be better...
> 
> > 
> > - 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/47da0ff3/attachment-0002.html>