[M3devel] barrier labels?

[Jay K]

I don't know. There is so much unknown here. It is frustrating and difficult.
We could use an extensive set of test cases.
  Or know more about the test cases we do have.
And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not.

tangent:

I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat
directory per architecture. I guess it's just a matter of a little code.
    It should just skip the few errors that are cross problems, which I should fix anyway.
    That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int
       if doing a native build, and assert that the results match.
I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3.
Can't ship m3core/libm3 for cross building.
I guess, and I forgot this, I should have used -x for override. Duh.
That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops.


 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 12 Jul 2010 09:43:01 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] barrier labels?
>
> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>