[M3devel] loophole/copysign
Jay K
jay.krell at cornell.edu
Mon Jul 5 11:24:20 CEST 2010
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 <M3_CtKayy_res, 8, 56> = (word_8) ((int_64)
BIT_FIELD_REF <M3_CtKayy_res, 8, 56> & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF <M3_CtKayy_y, 8, 56>, 1, 7> << 7 & 255);
<retval> = M3_CtKayy_res;
return <retval>;
}
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;
<unnamed type> D.1917;
struct float_t * from.1;
struct float_t * res.0;
<bb 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
More information about the M3devel
mailing list