[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