[M3devel] loophole/copysign

[Tony Hosking]

OK, so now I begin to understand.  What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types.  What happens in C code where you cast a memory location from one type to another?   How does gcc cope with that?  Presumably it gets some sort of type aliasing information?

On 5 Jul 2010, at 17:42, Jay K wrote:

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