[M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3

Jay K jay.krell at cornell.edu
Tue Jul 6 21:20:04 CEST 2010


Right, that's what I meant by "too conservative".
The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it?
  Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimizing.
  I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the
  algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now)

btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit
optimizations if/when they cause other problems.

 - Jay

----------------------------------------
> Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3
> From: hosking at cs.purdue.edu
> Date: Tue, 6 Jul 2010 09:58:19 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case?
>
> On 6 Jul 2010, at 08:28, Jay K wrote:
>
> >
> > Ok, this is interesting. I think. Finally.
> > I need to test more, but it is looking very promising. I think you'll like it (Tony).
> > I still don't understand all the flow around the front end. I had to try out some guesses.
> > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations.
> > This change might actually be too conservative.
> > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't.
> > I guess S (struct) can't really be float.
> >
> >
> > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float).
> > So the conservativeness is somewhat sensible.
> > Limiting it to D_to_S, though, unclear.
> >
> >
> > The change is just inserting CG.Force().
> >
> >
> > OK? (Let me test a bit more -- build the entire tree.)
> >
> > This appears to let me leave "ter" on.
> > I can try leaving other optimizations on.
> >
> >
> > Index: exprs/CastExpr.m3
> > ===================================================================
> > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v
> > retrieving revision 1.9
> > diff -u -r1.9 CastExpr.m3
> > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9
> > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000
> > @@ -10,6 +10,7 @@
> >
> > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType;
> > IMPORT M3, M3ID, M3RT, Target, TInt;
> > +FROM Target IMPORT FloatType;
> >
> > TYPE
> > Kind = {
> > @@ -394,7 +395,7 @@
> > u := Expr.TypeOf (e);
> > t := p.tipe;
> > sz, t_align, u_align, z_align: INTEGER;
> > - u_cg: CG.Type;
> > + u_cg, t_cg: CG.Type;
> > u_info, t_info: Type.Info;
> > BEGIN
> > u := Type.CheckInfo (u, u_info);
> > @@ -403,6 +404,7 @@
> > u_align := u_info.alignment;
> > z_align := MAX (t_align, u_align);
> > u_cg := u_info.stk_type;
> > + t_cg := t_info.stk_type;
> > sz := u_info.size;
> > Type.Compile (t);
> > Type.Compile (u);
> > @@ -416,6 +418,15 @@
> > Kind.V_to_V =>
> > Expr.CompileLValue (p.expr, traced);
> > CG.Boost_alignment (t_align);
> > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core:
> > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign':
> > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371
> > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign':
> > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371
> > +*)
> > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN
> > + CG.Force ();
> > + END;
> >
> > | Kind.D_to_A,
> > Kind.S_to_A,
> >
> >
> >
> > (577) begin_procedure
> > procedure LongFloat__CopySign
> > LongFloat__CopySign(578) set_source_line
> > source line 117
> > (579) load
> > type:lreal
> > type:lreal
> > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal
> > (580) store
> > type:lreal
> > type:lreal
> > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal
> > (581) set_source_line
> > source line 119
> >
> >
> > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct)
> >
> >
> > (582) load_address
> > load address (M3_CtKayy_res) offset 0x0
> > (583) load_address
> > load address (M3_CtKayy_y) offset 0x0
> > (584) load_indirect
> > type:word8
> > type:int64
> > load address offset:0x38 src_t:word8 dst_t:int64
> > (585) extract_mn
> > type:int64
> > extract_mn offset:7 count:1 sign_extend:0
> > (586) swap
> > type:addr
> > type:int64
> > (587) declare_temp
> > type:addr
> > temp var type:addr size:0x40 alignment:0x40
> > (588) store
> > type:addr
> > type:addr
> > store (noname) offset:0x0 src_t:addr dst_t:addr
> > (589) load
> > type:addr
> > type:addr
> > m3cg_load (noname): offset 0x0, convert addr -> addr
> > (590) load_indirect
> > type:word8
> > type:int64
> > load address offset:0x38 src_t:word8 dst_t:int64
> > (591) swap
> > type:int64
> > type:word8
> > (592) insert_mn
> > type:int64
> > insert_mn offset:7 count:1
> > (593) load
> > type:addr
> > type:addr
> > m3cg_load (noname): offset 0x0, convert addr -> addr
> > (594) swap
> > type:word8
> > type:addr
> > (595) store_indirect
> > type:int64
> > type:word8
> > store indirect offset:0x38 src_t:int64 dst_t:word8
> > (596) set_source_line
> > source line 120
> > (597) load
> > type:lreal
> > type:lreal
> > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal
> > (598) exit_proc
> > type:lreal
> > (599) free_temp
> > (600) end_procedure
> > procedure LongFloat__CopySign
> >
> >
> >
> > - Jay
> >
> >
>
 		 	   		  


More information about the M3devel mailing list