<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I don't understand.<BR>
<BR>
<BR>
-O3 is I think broken wherever there is try/lock/vfork.<BR>
I assume there is one fix for all, not any "one offs".<BR>
Granted, maybe vfork is pretty rare is reasonable to fix each occurence somehow.<BR>
<BR>
<BR>
-O2 is seemingly broken too.<BR>
On AMD64_LINUX I get to:<BR>
<BR>
--- building in AMD64_LINUX ---<BR>
ignoring ../src/m3overrides<BR>
new source -> compiling RTHooks.i3<BR>
<BR>***<BR>*** runtime error:<BR>*** <*ASSERT*> failed.<BR>*** file "../src/values/Value.m3", line 52<BR>***<BR>
<BR>
and haven't looked further.<BR>
<BR>
<BR>
I assume volatile is a big part of a possible answer, except that:<BR>
- need not mark every local volatile, not even in functions that call setjmp <BR>
- only need volatile on locals used within both the "try" and the "finally" <BR>
"used" is overkill, like, if it is just a temp variable and the finally block's first use is a store and not a read, then no need to preserve the value out of the "try" <BR>
- even that is overkill, you don't want to completely deoptimize use of those locals, just be sure to "home" them at any function call site if they are in registers<BR>
<BR>
<BR>
If we were writing in C, we would just use the pessimistic approach of programmer applying volatile where the compiler warns -- on locals used within try and finally (so to speak, it's really use after both setjmp returns or somesuch). I guess globals are ok no matter what.<BR>
<BR>
<BR>
We can possibly do better than that though as I said. The portable C fix is overkill since "temporary enregistration" is safe. Well, er, I guess what a C programmer might do, if he wanted the more optimal form, is have two sets of locals, "normal" and "volatile" and would copy to/from after each setjmp return and at otherwise required times -- before any function calls that follow modification of the "normal" locals.<BR>
<BR>
something like:<BR>
void F()<BR>
{<BR> int i;<BR>
volatile int vi;<BR>
jmp_buf jb;<BR>
if (setjmp(jb) == 0) /* try */<BR>
{<BR>
for (i = 0; i < 100; ++i)<BR>
{<BR>
/* use i somehow */ <BR> vi = i; /* store vi before possible longjmp */ <BR>
F();<BR>
}<BR>
}<BR>
else /* finally */<BR>
{<BR>
i = vi; /* get i from vi's home */ <BR>
/* use i somehow */ <BR> }<BR>
<BR>
<BR>
Though it'd be a bit tedious/fragile.<BR>
<BR>
<BR>
I'm skeptical we can do a very good job here, not sure (er, just don't know..) what information is available where. Marking all the locals volatile in a function that calls setjmp might be the best we can do, and try to eliminate all setjmps in favor of stack walkers...<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> From: hosking@cs.purdue.edu<BR>> To: jay.krell@cornell.edu<BR>> Date: Mon, 11 May 2009 19:15:49 +1000<BR>> CC: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> I'm not convinced there is any more -O3 breakage than this.<BR>> <BR>> On 11 May 2009, at 17:42, Jay wrote:<BR>> <BR>> ><BR>> > ps: We load/store everything as a bitfield as I understand..I wonder <BR>> > if that is a problem, like, given that bitfields aren't addressible..<BR>> ><BR>> > (which is not to say that they can't be volatile, and bitfields are <BR>> > often used to "map to hardware interfaces" so maybe this is <BR>> > irrelevant)<BR>> ><BR>> ><BR>> ><BR>> > Tony -- your change..is it reasonable/useful in light of larger <BR>> > related -O3 breakage?<BR>> ><BR>> ><BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> > From: jay.krell@cornell.edu<BR>> > To: hosking@cs.purdue.edu<BR>> > CC: m3commit@elegosoft.com<BR>> > Subject: RE: [M3commit] CVS Update: cm3<BR>> > Date: Mon, 11 May 2009 07:39:16 +0000<BR>> ><BR>> ><BR>> ><BR>> > ah. Notice that m3_load/m3_store mark a lot of things volatile.<BR>> > I'm trying out a wild guess and marking "v" volatile before the <BR>> > offseting in those functions..<BR>> ><BR>> > I guess though you've revealed the answer -- strive for like I said <BR>> > -- mark anything volatile referenced in finally or such. Er, <BR>> > anything referenced both in try and finally, something like that. <BR>> > Initial lameness would be all locals in a function with try/finally/ <BR>> > lock. And, gosh, I hope they don't enregister globals. :(<BR>> > You'd want some volatile on globals too.<BR>> > Only the uses in a try where the function also references them in a <BR>> > finally<BR>> <BR></body>
</html>