[M3devel] barrier labels?
Jay K
jay.krell at cornell.edu
Mon Jul 12 01:41:20 CEST 2010
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
> >
>
More information about the M3devel
mailing list