<html><head><base href="x-msg://1304/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Surely we can give the backend enough opaque information about record types (size, alignment, etc.) without revealing their complete structure... So, layout is still computed by the front-end and the back-end just sees a bag of bits. Or is that the exact problem you are facing...<div>
<br><div><div>On 1 Sep 2010, at 00:26, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; "> > I don't particularly understand the SPARC64_SOLARIS issue<br> <br> <br>When a record is passed by value SPARC64_SOLARIS backend goes to figure<br>out the ABI for it and it hits an assertion failure.<br> <br> <br>Historically no type was associated with parameters and locals in the backend.<br>At least not for records.<br>Maybe they had a size and an alignment.<br>But certainly no fields.<br> <br> <br>You know -- imagine a record with non-zero size but zero fields. Wierd eh?<br>The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion.<br> (gcc can cope with some such cases the comments say, but still..)<br> <br> <br>If you start but don't finish fixing this problem, by giving types to parameters,<br>you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets.<br>I don't fully understand/remember the problem, but it is easy to uncover.<br> <br> <br>Part of the problem was plain missing type information -- I fixed that in m3front.<br>If you both imported and defined a type, you wouldn't get the information.<br> m3front was deliberately skipping imported types, even if they coincided with locally defined types.<br>If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now,<br>if the supertype matches.<br> <br> <br>That's still not the extent of the problem on AMD64_DARWIN though.<br> <br> <br>Test case p247 covers much of this.<br>It just passes a record with a pointer and integer by value.<br>Two integers (in record) have same problem.<br> <br> <br>To try to summarize:<br> There has been a historical lack of use of type information in the backend.<span class="Apple-converted-space"> </span><br> Mostly the backend does get good type information from frontend, but<br> it didn't associate it with locals/parameters. And it is better now.<span class="Apple-converted-space"> </span><br> (globals are worse still I believe)<br> <br> <span class="Apple-converted-space"> </span><br> I'm not 100% sure, but it appears to me that both the frontend and backend layout records.<br> That is, determine the offset of each field, such as by adding up the sizes of preceding fields.<br> (It is more involved than that, due to alignment.)<br> I am concerned that these two layouts might not agree, and the result would be terrible.<br> <br> <br>- Jay<br><br> <br><hr id="stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Tue, 31 Aug 2010 22:22:16 -0400<br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] a trouble with passing records by value..<br><br>I believe there is one way out here.<div>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.</div><div>We can even rely on Modula-3 run-time support to interpret the UIDs.</div><div><br></div><div>I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate?</div><div><br><br><div><div>On 31 Aug 2010, at 22:00, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Tahoma; font-size: 10pt; ">> I strongly advise against that hack.<br><br> <br>It's not my favorite, but I'm possibly in<br>a jam here between providing type information<br>for debugging with stock gdb, and I suspect an<br>overall poor story regarding type information<br>and backend/frontend interface.<br> <br> <br>One option is to give up on type information.<br>i.e. go back to the historical way i.e. before August 2010.<br>That worked ok as far as most people observed (except for stock gdb..)<br>However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS.<br> <br><br>I suspect we never historically passed records in registers, and that we must continue not to.<br> Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if<br> it notices their address taken.<br><br> <br>It might suffice, besides giving up on type information, to<br>mark all records as "addressable". Or, again, to slightly<br>hack the backend. Maybe only for SPARC64.<br> <br> <br>The bigger controversial question is if we should change<br>m3cg (the interface) to know about "field references".<br> <br><br>And then, again, should layout be done by the frontend, backend,<br>or both? There are arguments for all three options.<br>I think the current *design* is frontend only.<br>But I think the current *implementation* is both (except for NT386).<br>And probably the right way is backend only.<br> <br><br>This would also generally fix the pesky "load/store use bitfields" thing.<br> <br> <br>Debuggability with stock gdb does seem like a nice idea.<br>But I see now it might conflict tremendously with our odd structuring.<br> <br> <br>I'll keep poking at it. e.g.: good type information, including for temporaries,<br>and mark all record types/values as addressable.<br> <br> <br>We should still consider the notion of "field references" in the m3cg interface.<br> Right? I'm not crazy in the "mismatch" I seem to "detect"?<br>Probably besides given the field "name", we should pass what the frontend<br>thinks is the offset, type, alignment. This will serve two purposes.<br>For NT386, it will let it continue to be fairly typeless, at least for now.<br>For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed.<br> <br> <br>I still have to understand how bitfields fit here also.<br>Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes!<br> <br><br> - Jay<br><br><br> <br>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Tue, 31 Aug 2010 20:58:07 -0400<br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] a trouble with passing records by value..<br>><span class="ecxApple-converted-space"> </span><br>><span class="ecxApple-converted-space"> </span><br>><span class="ecxApple-converted-space"> </span><br>> On 31 Aug 2010, at 19:09, Jay K wrote:<br>><span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><br>> > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.<br>> > Yucky.<br>><span class="ecxApple-converted-space"> </span><br>> I strongly advise against that hack.<br>><span class="ecxApple-converted-space"> </span><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>><span class="ecxApple-converted-space"> </span><br>> This would be better...<br>><span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><br>> > - Jay<br>> ><span class="ecxApple-converted-space"> </span><br>> > ----------------------------------------<br>> >> From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> To:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Subject: RE: [M3devel] a trouble with passing records by value..<br>> >> Date: Tue, 31 Aug 2010 23:05:08 +0000<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> t1 must still be passed in registers. The ABI can't be changed by that.<br>> >><span class="ecxApple-converted-space"> </span><br>> >> - Jay<br>> >><span class="ecxApple-converted-space"> </span><br>> >> ----------------------------------------<br>> >>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>> Date: Tue, 31 Aug 2010 09:15:32 -0400<br>> >>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >>> Subject: Re: [M3devel] a trouble with passing records by value..<br>> >>><span class="ecxApple-converted-space"> </span><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>> >>><span class="ecxApple-converted-space"> </span><br>> >>> On 31 Aug 2010, at 07:25, Jay K wrote:<br>> >>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> Given something like this:<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> jbook2:p247 jay$ more 1.c<br>> >>>> #include<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> typedef struct { long code; long value; } T1;<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> void ActionLookup(T1 t, long code, long value);<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> void ActionLookup(T1 t, long code, long value)<br>> >>>> {<br>> >>>> assert(t.code == code);<br>> >>>> assert(t.value == value);<br>> >>>> }<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> int main()<br>> >>>> {<br>> >>>> T1 t1 = {2,2};<br>> >>>> ActionLookup(t1, 2, 2);<br>> >>>> return 0;<br>> >>>> }<br>> >>>> j<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good.<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><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>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> If m3cg were higher level this could be better.<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><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>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> Maybe we should have M3CG include field references?<br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><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>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>><span class="ecxApple-converted-space"> </span><br>> >>>> - Jay<br></div></span></blockquote></div><br></div></div></span><br class="Apple-interchange-newline"></blockquote></div><br></div></body></html>