[M3devel] passing structs by value

[Jay K]

Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them.

 > Of course, at the machine levelI'm talking about the machine level.

Passing a record by value can be in registers or a pointer to a copy.
The gcc backend wasn't passing enough type information around, such that
where the C ABI specified in registers, it'd a be a pointer to a copy.
   Imho, it's kind of bad of the gcc code to even have accepted the trees we give it.
I don't much mind the inefficiency, but I do mind missing type information in the debugger.

And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend.
It goes to decide how to pass a record by value, which includes looking at what fields the record
has, and it had none. Which it is sometimes ok with, but not in this case.

If you just change parse.c to pass around the type information it has, well, the easy
code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash.
The badness only occurs in a little bit of code in the system, and then, only on some platforms.
I was lucky to be using such a platform!

I have fixed it now so that the passer and recieve both have the information.

The result should be, on some platforms, depending on the ABI, depending on the exact RECORD,
some records will be passed in registers.
Minor side benefit is correct interop with C, though I'd suggest just staying away from
passing records by value with C.

Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :(
I'm double checking to make sure I used current source. Accidentally doing
a clean build of m3cc, so it'll be a while.


 - Jay


----------------------------------------
> Date: Fri, 27 Aug 2010 10:30:15 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] passing structs by value
>
> Jay, I am not sure what you are saying here, but it sounds like you might be considering the
> passing mode of records to be an implementor choice. Have I read this right?
>
> It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the
> signature, reference for VAR, and for READONLY, it depends on the form of the actual.
>
> For function returns, the semantics are always by value.
>
> Of course, at the machine level, you can always pass a pointer between caller and callee,
> as long as the necessary copying is done somewhere This is the only reasonable way to
> implement READONLY, since whether a copy is to be made will differ at different call
> sites.
>
> Jay K wrote:
> > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI.
> >
> > I really can't follow the complicated rules here:
> >
> > http://www.x86-64.org/documentation/abi-0.99.pdf
> >
> >
> >
> > but suffice it to say, records can be passed in registers, but it depends on the types of their fields.
> >
> >
> >
> > As much as we don't pass/return records by value between Modula-3 and C, that is ok.
> > As long as Modula-3 callers/recievers agree. And they do, but...
> >
> >
> > The gcc backend is given good type information at first, but historically throws much of it away.
> > As you start to repair that, it starts following the ABI. At least at the callee side.
> > I think the caller is still devoid of type information.
> > I'm assuming there is a fallback rule for the case of missing type information.
> >
> > So if you give just one side the type information, you get a mismatch, bad code.
> >
> >
> > Passing records in registers is nice, but..
> > (reminder: I think historically we never did).
> >
> >
> > I thin we should probably just change the frontend to handle passing records by value itself.
> > Like it does for I386_NT/NT386.
> >
> >
> > For any record parameter, introduce a temporary in the caller and pass its address.
> > Or whatever the code is already prepared to do.
> >
> >
> > We should probably handle records returned by value similarly.
> >
> >
> > This decision can be revisited if/when there is a C backend.
> > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it.
> > I doubt anyone else is either.
> > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work.
> > Further long term deficiencies this uncovers, I'm very inclined to dig further into.
> >
> >
> > The right fix is probably to maintain types in the expression stack.
> > Or at least throw in more casts on the pops.
> >
> >
> > I don't think pop_param presently recieves enough type information -- no type id.
> >
> >
> > - Jay
> >