[M3commit] CVS Update: cm3

[Jay]

I don't understand.

 

 

-O3 is I think broken wherever there is try/lock/vfork.

I assume there is one fix for all, not any "one offs".

Granted, maybe vfork is pretty rare is reasonable to fix each occurence somehow.

 

 

-O2 is seemingly broken too.

On AMD64_LINUX I get to:

 

--- building in AMD64_LINUX ---

ignoring ../src/m3overrides

new source -> compiling RTHooks.i3


***
*** runtime error:
***    <*ASSERT*> failed.
***    file "../src/values/Value.m3", line 52
***

 

and haven't looked further.

 

 

I assume volatile is a big part of a possible answer, except that:

 - need not mark every local volatile, not even in functions that call setjmp 

 - only need volatile on locals used within both the "try" and the "finally" 

   "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" 

 - 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

 

 

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.

 

 

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.

 

something like:

void F()

{
  int i;

  volatile int vi;

  jmp_buf jb;

  if (setjmp(jb) == 0) /* try */

 {

     for (i = 0; i < 100; ++i)

     {

      /* use i somehow */ 
       vi = i; /* store vi before possible longjmp */ 

       F();

    }

 }

 else /* finally */

 {

   i = vi; /* get i from vi's home */ 

    /* use i somehow */ 
 }

 

 

Though it'd be a bit tedious/fragile.

 

 

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...

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 11 May 2009 19:15:49 +1000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> I'm not convinced there is any more -O3 breakage than this.
> 
> On 11 May 2009, at 17:42, Jay wrote:
> 
> >
> > ps: We load/store everything as a bitfield as I understand..I wonder 
> > if that is a problem, like, given that bitfields aren't addressible..
> >
> > (which is not to say that they can't be volatile, and bitfields are 
> > often used to "map to hardware interfaces" so maybe this is 
> > irrelevant)
> >
> >
> >
> > Tony -- your change..is it reasonable/useful in light of larger 
> > related -O3 breakage?
> >
> >
> >
> > - Jay
> >
> >
> >
> > From: jay.krell at cornell.edu
> > To: hosking at cs.purdue.edu
> > CC: m3commit at elegosoft.com
> > Subject: RE: [M3commit] CVS Update: cm3
> > Date: Mon, 11 May 2009 07:39:16 +0000
> >
> >
> >
> > ah. Notice that m3_load/m3_store mark a lot of things volatile.
> > I'm trying out a wild guess and marking "v" volatile before the 
> > offseting in those functions..
> >
> > I guess though you've revealed the answer -- strive for like I said 
> > -- mark anything volatile referenced in finally or such. Er, 
> > anything referenced both in try and finally, something like that. 
> > Initial lameness would be all locals in a function with try/finally/ 
> > lock. And, gosh, I hope they don't enregister globals. :(
> > You'd want some volatile on globals too.
> > Only the uses in a try where the function also references them in a 
> > finally
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090511/3e517f8a/attachment-0002.html>