[M3devel] barrier labels?

[Tony Hosking]

No, that code came from 4.x...




On 11 Jul 2010, at 19:41, Jay K wrote:

> 
> Tony, thanks for the pointer..though I haven't been able to find it yet.
> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time.
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sun, 11 Jul 2010 16:25:41 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] barrier labels?
>> 
>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets.
>> 
>> On 11 Jul 2010, at 07:46, Jay K wrote:
>> 
>>> 
>>> Tony, six years ago you introduce what is now:
>>> 
>>> 
>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6
>>> 
>>> 
>>> static void
>>> m3cg_set_label (void)
>>> {
>>> ...
>>> if (barrier)
>>> {
>>> ...
>>> {
>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels;
>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels
>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list);
>>> }
>>> ...
>>> 
>>> 
>>> I'm not sure what to do here for gcc 4.5.
>>> The data has moved around and isn't available this early. I suppose we could hang some information on and
>>> deal with it later in compilation.
>>> 
>>> 
>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient).
>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone.
>>> 
>>> 
>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN.
>>> And Juno/mentor/tetris work without optimization, I'll test optimized later.
>>> Next I'll test -O2, -O3, m3-sys/m3tests.
>>> 
>>> 
>>> Do we have good exception handling tests?
>>> I know that cm3 uses exceptions, like, looking for cm3.cfg.
>>> 
>>> 
>>> I'll poke around more..
>>> 
>>> 
>>> - Jay
>>> 
>> 
>