[M3devel] barrier labels?

[Tony Hosking]

Perhaps we just need FORCED_LABEL for these:

/* In a LABEL_DECL, nonzero means this label had its address taken
   and therefore can never be deleted and is a jump target for
   computed gotos.  */


On 11 Jul 2010, at 23:03, Jay K wrote:

> 
> I still don't see it, in the C++ frontend.
> 
> There is:
> 
> void
> expand_label (tree label)
> {
> ...
>   if (DECL_NONLOCAL (label))
>     {
> ...      nonlocal_goto_handler_labels
>     = gen_rtx_EXPR_LIST (VOIDmode, label_r,
>                  nonlocal_goto_handler_labels);
>     }
> 
> but I don't think this works until later.
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sun, 11 Jul 2010 20:52:25 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] barrier labels?
>> 
>> 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
>>>>> 
>>>> 
>>> 
>> 
>