[M3devel] loophole/copysign

[Jay K]

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