[M3devel] reducing use of volatile in backend?

[Jay K]

I've had *a lot* of success here the past few hours.
 
 
There is an assert starting up mentor I need to look at, possibly out of data binaries.
  The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
 
 
Compiler seems to work.
  Lots of things do break it, so that is something.
 
 
Various gui apps startup.
  Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
 
 
 
Here is what I have:
 
  The vast vast majority of optimizations can be enabled.
 
  Nearly all uses of volatile can be removed.
 
  Just a few optimizations "need" to be disabled.
 
In particular:
 I only have volatile remaining:
    on store after insert_mn (special case)
 
    floating point (huh? wierd)
     compile errors without this 
 
    in functions that call setjmp or vfork
      This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
 
 
    on the load/store in loophole
      compile errors without this; perhaps redundant with the floating point check
 
 
    on load link, else it gets uninitialized warning 
 
 
 
Also I found a likely bug.
In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
 
  
 
 
 The optimizations I disabled, from memory:
 
 
  pre - partial redundancy elimination 
 
 
  fre - full redundancy elimination (these are related) 
    One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
 
 
  loop im (induction motion) - caused a compile error in Trestle 
 
  vrp - value range propagation
     This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
 
 
  insn_sched - wierd, caused a compile break
    but insn_sched_after_reload ok
 
 
 That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
  salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
 
 
I can compile the entire system, though I get lots of warnings about uninitialized variables.
I pass the backend the -Wuninitialized flag.
 
 
I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
We can iterate more on the remaining optimizations.
 
 
Getting good typeinfo would be good so that gdb can debug.
And maybe so that other than stabs works.
 
 
 - Jay




----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 16:05:30 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] reducing use of volatile in backend?
>
> We don't want to disable optimisations for types where it makes sense
> to have them. Better to smarten up typebased alias analysis instead so
> we can get rid of volatile properly.
>
> Sent from my iPhone
>
> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>
>>
>> Tony, would we maybe be better off not using volatile everywhere but
>> selectively turning off optimizations in m3_post_options?
>> You know, using volatile probably disables more than necessary?
>> I'm experimenting with this.
>>
>> - Jay
>>
>>
>>
>>
>>