[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