[M3devel] loophole/copysign

Mon Jul 5 22:49:14 CEST 2010

The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest.
Let me know if attached is ok to commit.
The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all.

Thanks,
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 5 Jul 2010 14:26:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] loophole/copysign
>
> We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice.
>
>
> On 5 Jul 2010, at 08:56, Jay K wrote:
>
> >
> > nope.
> > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly,
> > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries
> > in current function as volatile?
> >
> > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest].
> >
> > It would be available as a desparate measure if we find other problems.
> > To selectively inhibit optimization a function at a time.
> > Which, granted, is generally overkill.
> >
> > I'm trying this now..
> > - Jay
> >
> > ----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: m3devel at elegosoft.com
> >> Subject: RE: [M3devel] loophole/copysign
> >> Date: Mon, 5 Jul 2010 11:36:11 +0000
> >>
> >>
> >> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: volatile.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100705/2530f6bf/attachment-0002.txt>