<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br><BR>I don't know. It makes me nervous.<BR>I though we effectively turn off TBAA in m3cc, and I can imagine what our trees looke like in C, and it seems my C code might look about the same. As well, you know..it seems like a bug in gcc, at which point, your system of thinking about things breaks down and we have to understand the actual buggy behavior instead of the expected reasonable behavior. For now I'm not passing any optimizer flags to the C compiler. I don't remember if I tried that yet.<BR> <BR> <BR>I have to keep in mind priorities: <BR> <BR>support uplevel locals in sub-blocks -- so m3-tk compiles <BR> reorder stuff so module data is initialized, or at least fully declared, up front -- so the code is valid C++ -- I currently run afoul of a corner case and generate valid C that isn't valid C++ <BR> <BR>maybe only output helper functions that are used -- i.e. work on gcc -Wall -- this is easy with the multipass support <BR> <BR>move all imports/declarations up front, instead of at arbitrary places -- just slight cleanliess -- easy with the multipass support <BR> only declare frame types when needed -- easy now too, slightly cleaner code <BR> <BR>Work on getting structs/records declared strongly typed -- should be easy.<BR>Work on making loads/stores be field access -- slightly challenging to do this efficiently, since we have to map offset/sizes to fields.<BR> <BR>Somewhere along the line also, I have to stop producing all these temporary strings and produce a proper typed hiearchical representation -- like an "expression", a "plus node" with two sub expressions. So for example, I don't cast same type to same type. It will actually likely resemble the gcc trees!<BR> <BR> Sprinkling volatile on every variable declaration (but not access) is not a big deal right now.<BR>And volatile might be a good idea -- separate mail on this.<BR> <BR> <BR> - Jay<br> <BR><br><br><br> <BR><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">Subject: Re: [M3devel] deeper meaning of in_memory?<br>From: hosking@cs.purdue.edu<br>Date: Fri, 28 Sep 2012 18:27:30 -0400<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br>Good question. But if you are good about making the structs anonymous and taking their address then TBAA in C should not give you problems.<br>
<br><div><div>On Sep 28, 2012, at 3:31 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div style="font: 12pt/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; orphans: 2; widows: 2; font-size-adjust: none; font-stretch: normal;" class="ecxhmmessage"><div dir="ltr">> structs volatile<br><br>Mainly paranoia.<div>But I do wonder if the breakage I saw in gcc's "sra" optimization pass (structure replaced by aggregate) by feeding it trees can be reproduced from C. I should look into that...</div><div><br></div><div><br></div><div> - Jay<br><br><div><div id="ecxSkyDrivePlaceholder"></div><hr id="ecxstopSpelling">Subject: Re: [M3devel] deeper meaning of in_memory?<br>From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 28 Sep 2012 10:11:49 -0400<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br>in_memory does not mean volatile. It is simply a sign that its address is needed.<div>So, yes, taking its address is good enough.</div><div>An example of a local in memory is something passed by VAR.</div><div><br></div><div>So, NOT VOLATILE.</div><div><br></div><div>Why do structs need to be C volatile?<br><br><div><div>On Sep 27, 2012, at 10:57 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div style="font: 12pt/normal Calibri; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white-space: normal; orphans: 2; widows: 2; font-size-adjust: none; font-stretch: normal;" class="ecxhmmessage"><div dir="ltr">In M3CG, what is the deeper meaning of in_memory?<div>I know it means -- "put the thing in memory".</div><div>But why and exactly what?<br>Presumably it can also be in a register, just that the in-memory value must be kept up to date.</div><div>Like, stores should be volatile, but reads don't have to be?</div><div>Does it mean the value will be used in an exception/finally handler?</div><div>Maybe reads do need to be volatile? Maybe it is accessed by another thread w/o a lock?</div><div><br></div><div><br></div><div>If I take the address of something, is that good enough?</div><div><br></div><div><br></div><div>I should just look where m3front uses it, I know.</div><div>For now I'll probably take it to mean "volatile".</div><div>I already mark all structs as volatile. But I don't make everything volatile (like how m3cc long did).</div><div><br></div><div><br></div><div>Thanks,</div><div> - Jay</div></div></div></blockquote></div></div></div></div></div></div></blockquote></div><br></div> </div></body>
</html>