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

Tony Hosking hosking at cs.purdue.edu
Tue Jul 6 21:23:47 CEST 2010


On 6 Jul 2010, at 15:20, Jay K wrote:

> Right, that's what I meant by "too conservative".

I am ok with forcing in all D_to_S cases.

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

I don't think that will happen with the force, since we will make it in memory for gcc which will probably then be much happier.

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

OK, great.

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

I am extremely leery of introducing hacks into the IR that we will later regret.  The rot will set in...

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