[M3devel] loophole/copysign

[Tony Hosking]

None of this is making much sense to me...

On 5 Jul 2010, at 16:51, Jay K wrote:

> 
> I think this is still a good idea but I don't think relevant here.
> There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure.
> 
> I think a temporary would still work, in the "LV" D_to_S variant.
> But a temporary is wrong for the non-LV case, due the need to preserve writes to the original.
> But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Mon, 5 Jul 2010 14:25:17 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] loophole/copysign
>> 
>> Yes, maybe that is the best way forward.
>> 
>> On 5 Jul 2010, at 07:36, Jay K wrote:
>> 
>>> 
>>> another idea: let's not use bitfield ref for float/double
>>> 
>>> - Jay
>>> 
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Mon, 5 Jul 2010 11:25:19 +0000
>>>> Subject: Re: [M3devel] loophole/copysign
>>>> 
>>>> 
>>>> Hm. it seems that it might be important to preserve the "designatorness", like in:
>>>> 
>>>> libm3/...RandomReal.m3:
>>>> 
>>>> VAR frac, exp: INTEGER; result: LONGREAL;
>>>> 
>>>> (* Repack as LONGREAL: *)
>>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO
>>>> lr.sign := 0;
>>>> lr.exponent := exp;
>>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff),
>>>> -(WordSize - 1 - FractionBits));
>>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff);
>>>> END;
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000
>>>>> Subject: Re: [M3devel] loophole/copysign
>>>>> 
>>>>> 
>>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"?
>>>>> 
>>>>> 
>>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html
>>>>> 
>>>>> An identifier is a writable designator
>>>>> if it is declared as a variable,
>>>>> is a VAR or VALUE parameter,
>>>>> is a local of a TYPECASE
>>>>> or TRY EXCEPT statement,
>>>>> or is a WITH local that is bound to a writable designator.
>>>>> An identifier is a readonly designator if it is
>>>>> a READONLY parameter,
>>>>> a local of a FOR statement,
>>>>> or a WITH local bound to a non-designator or
>>>>> readonly designator.
>>>>> 
>>>>> 
>>>>> 
>>>>> I guess a designator is what I would think of a "variable" or "read only variable"?
>>>>> Something that either is "in memory" or can "reasonably" be put there?
>>>>> 
>>>>> 
>>>>> 1 + 2 is not a designator.
>>>>> 
>>>>> 
>>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables"
>>>>> 
>>>>> 
>>>>> Anything with a name??? (not functions/modules/generics -- "named data")
>>>>> 
>>>>> 
>>>>> Anyway, the next questions include:
>>>>> 
>>>>> 
>>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"?
>>>>> I realize, probably a deoptimization.
>>>>> I think this lets the backend work.
>>>>> 
>>>>> 
>>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more?
>>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy.
>>>>> 
>>>>> 
>>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare..
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000
>>>>>> Subject: [M3devel] loophole/copysign
>>>>>> 
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>