[M3devel] loophole/copysign

[Jay K]

Specifically it goes down the "D_to_S" and "LV" paths (PrepLV, CompileLV, and not Prep and Compile, no temporary, no loophole)


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] loophole/copysign
> Date: Mon, 5 Jul 2010 21:42:43 +0000
>
>
> CastExpr.m3 has precious few calls to CG.Loophole, including none for this case.
> cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole.
> We store into a local as one type and read it back as another type.
>
>  - Jay
>
> ----------------------------------------
> > From: hosking at cs.purdue.edu
> > Date: Mon, 5 Jul 2010 17:33:43 -0400
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] loophole/copysign
> >
> > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr?
> >
> > On 5 Jul 2010, at 16:44, Jay K wrote:
> >
> > >
> > > I don't think a barrier worked.
> > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information.
> > > Or, well, it does have enough information, but, like, it is information it never uses.
> > > It has some type information. It would have to notice that the most recent store to a variable was
> > > of a different type than a load.
> > >
> > > - Jay
> > >
> > >
> > >
> > > ----------------------------------------
> > >> Subject: Re: [M3devel] loophole/copysign
> > >> From: hosking at cs.purdue.edu
> > >> Date: Mon, 5 Jul 2010 14:24:01 -0400
> > >> CC: m3devel at elegosoft.com
> > >> To: jay.krell at cornell.edu
> > >>
> > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need?
> > >>
> > >> On 5 Jul 2010, at 05:24, Jay K wrote:
> > >>
> > >>>
> > >>> Our codegen is remarkably low level. That is, lower level earlier than C.
> > >>>
> > >>>
> > >>> gcc/m3cg -ftree-dump-all
> > >>>
> > >>>
> > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have:
> > >>>
> > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y)
> > >>> {
> > >>> xreel M3_CtKayy__result;
> > >>> xreel M3_CtKayy_res;
> > >>>
> > >>> xreel M3_CtKayy__result;
> > >>> xreel M3_CtKayy_res;
> > >>> M3_CtKayy_res = M3_CtKayy_x;
> > >>> BIT_FIELD_REF = (word_8) ((int_64)
> > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255);
> > >>> = M3_CtKayy_res;
> > >>> return ;
> > >>> }
> > >>>
> > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have:
> > >>>
> > >>> copy_sign_f (from, to)
> > >>> {
> > >>> float res;
> > >>> float D.1918;
> > >>> D.1917;
> > >>> struct float_t * from.1;
> > >>> struct float_t * res.0;
> > >>>
> > >>> :
> > >>> res = to_1;
> > >>> res.0_4 = (struct float_t *) &res;
> > >>> from.1_5 = (struct float_t *) &from;
> > >>> D.1917_6 = from.1_5->sign;
> > >>> res.0_4->sign = D.1917_6;
> > >>> D.1918_7 = res;
> > >>> return D.1918_7;
> > >>>
> > >>> }
> > >>>
> > >>>
> > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions.
> > >>> Just integers and offsets from them mostly.
> > >>>
> > >>>
> > >>> The right fix is to build up types.
> > >>> That way also debugging with gdb will have a chance.
> > >>> Perhaps not a small amount of work. But maybe not too bad.
> > >>>
> > >>>
> > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes.
> > >>> At least if one type but not the other is floating point.
> > >>> I don't know if that will work, but maybe.
> > >>>
> > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or
> > >>> store volatile.
> > >>>
> > >>> - Jay
> > >>>
> > >>
> > >
> >
>