[M3commit] CVS Update: cm3

[Jay K]

ps: obviously the volatization that is there is overkill, but not too far off.
We only really need to volatize what is used in the except/finally blocks.
It might be a closer approximation to add volatile to anything referenced
in the function after we see the setjmp/fork call, instead of going and visiting
all current and future locals.
Even that is overkill.

I assume making the load/stores volatile is the same as making the variables volatile.
 So there are other similar approaches.
However I assume one dumb difference, evidenced by what you already did,
is that the warnings vary. The compiler doesn't notice, I guess, that if all
load/stores to a variable are volatile, then the variable itself is effectively volatile.

Anyway, ok for now.

Hm, maybe m3cg should offer volatile as a flag on parameters, locals, temporaries?
I'm not sure the backend knows where except/finally blocks are, after all.
This isn't the "make function volatile" thing I had, this is something narrower and
seems like it might fit better...except, well..volatile is maybe an implementation detail.
But you could just rename and get the same thing: "variable accessed in except/finally block".
Or, "start except block", "start finally block", "end except block", "end finally block".
?


 - 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: Wed, 7 Jul 2010 20:14:49 +0000
>
>
> That's still there, for "returns twice", like setjmp, fork and/or vfork.
> Not sure about longjmp.
> Not sure if it is adequate.
>    I saw PushFrame in the crashing example but I don't think I saw setjmp.
> Not sure about a few things.
>
>  - Jay
>
>
> ----------------------------------------
> > From: hosking at cs.purdue.edu
> > Date: Wed, 7 Jul 2010 15:59:08 -0400
> > To: jay.krell at cornell.edu
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> >
> > We already volatilise as necessary for setjmp/longjmp (at least we did when last I looked, because I remember putting it in).
> >
> > I would prefer to avoid volatile in all other situations where possible.
> >
> >
> > On 7 Jul 2010, at 15:54, Jay K wrote:
> >
> > >
> > > But I admit I'm nervous about removing all the volatile, esp. on stores.
> > > We should have a bunch of tests using exceptions that access locals/parameters in except and finally blocks.
> > > I'm willing to put back volatile on all stores.
> > > Or even loads if there is justification.
> > >
> > > I thought there'd be a setjmp in all functions with try/except/finally, and therefore the same
> > > pessimization, but now I'm not sure of that.
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > >> From: jay.krell at cornell.edu
> > >> To: hosking at cs.purdue.edu; jkrell at elego.de
> > >> Date: Wed, 7 Jul 2010 19:13:02 +0000
> > >> CC: m3commit at elegosoft.com
> > >> Subject: Re: [M3commit] CVS Update: cm3
> > >>
> > >>
> > >> Back when all loads and stores were volatile!
> > >> And the optimizer was severely hampered. Any optimized code I looked at was full of unnecessary code.
> > >> Which do you prefer?
> > >>
> > >> - Jay
> > >>
> > >> ----------------------------------------
> > >>> From: hosking at cs.purdue.edu
> > >>> Date: Wed, 7 Jul 2010 11:56:30 -0400
> > >>> To: jkrell at elego.de
> > >>> CC: m3commit at elegosoft.com
> > >>> Subject: Re: [M3commit] CVS Update: cm3
> > >>>
> > >>> This is new. It used to work!
> > >>>
> > >>>
> > >>> On 7 Jul 2010, at 08:20, Jay Krell wrote:
> > >>>
> > >>>> CVSROOT: /usr/cvs
> > >>>> Changes by: jkrell at birch. 10/07/07 08:20:57
> > >>>>
> > >>>> Modified files:
> > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> > >>>>
> > >>>> Log message:
> > >>>> partial redundancy elimination ('pre') also crashes compiling libm3/Formatter, add comment; remove all the other stuff about disabling optimizations
> > >>>
> > >>
> > >
> >
>