[M3devel] barrier labels?

[Jay K]

I forgot about this.
I never resolved it.
Things seem to work though.
?

 - Jay

> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Tue, 13 Jul 2010 06:38:05 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] barrier labels?
> 
> 
> 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
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>  		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100817/4d9e5c8f/attachment-0001.html>