[M3devel] reducing use of volatile in backend?

Wed Jun 2 16:30:05 CEST 2010

attached is the diff I'm working on.

It works well on a few platforms.
I've been using it on AMD64_DARWIN.
Cross I386_LINUX, PPC_DARWIN cm3 startup and give
  the correct message, which requires exception handling to work.

SOLgnu exception handling doesn't work.
MIPS64_OPENBSD internal errors a bunch in the compiler.
  Probably don't care. Don't know if it was working before.

Still to do:
  figure out what is up with SOLgnu/SOLsun

Not ideal but I think ok for now:
  volatizing all floating point
    We already were, though granted possibly with more optimizations.
  flag_unit_at_a_time = 0

flag_unit_at_a_time isn't "tricky" or subtle,
but it does remove a function we want to take the address of.
I couldn't find a way to get it to keep the function.

What I think is fine for a while:
  flag_tree_vrp = 0;
  flag_tree_pre = 0;
  flag_tree_fre = 0;

Maybe it doesn't take much to let them work?
Maybe wait until 4.5 is working and try again there?
  In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
  vrp is what silently produces non-working code.
  It is either the only one, or one of pre/fre also do.
  At least one of pre/fre crash, accessing null pointer.

and probably also ok for a "while":
 flag_tree_loop_im = 0
 flag_schedule_insns = 0

though for flag_schedule_insns = 0 to fail seems odd,
and flag_tree_loop_im only broke in a little code, should
probably look at that code.

Oh and I still need to see about fours/badbricks recieving mouse clicks.
Mine aren't.

The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
to compiler. The assert failed.

We might want to have the frontend tell the backend if the
target has a stack walker, instead of the logic I have here.

While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
constantly reloading registers from the stack.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] reducing use of volatile in backend?
> Date: Tue, 1 Jun 2010 21:55:31 +0000
>
>
> 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
>>>
>>>
>>>
>>>
>>>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: less-volatile.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100602/59c4b762/attachment-0002.txt>