[M3devel] barrier labels?

[Jay K]

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
> >>>
> >>
> >
>