[M3devel] M3CG loophole operator is not LOOPHOLE (but what?)

[Rodney M. Bates]

The issue I raised is not with the M3 LOOPHOLE builtin function.  The compiler
currently implements it correctly, according to the language definition, as
Tony quoted.  The front end verifies the size equality, as required by the
language, then emits an intermediate "loophole" operator, which will be same
size, and thus well-defined as equivalent to LOOPHOLE.  (And also llvm bitcast,
which is now being used to translate the loophole operator in this case.)

My issue is that there are 13 other places the front-end emits an internally
generated "loophole", and these (almost?) all can do so with unequal sizes.
Moreover, what should be done with the unequal sizes varies from place to place.

It is possible that the "loophole" operator can be defined to do what is
correct in every case by a conditional rule based on the two types.  I
need to do another pass through them to be sure.  This may be the quickest
way to get the llvm backend working, but I think it is not good design.
It would be carefully tailored to just a specific set of uses of "loophole",
instead of making a reasonable abstraction out of" loophole".  It would be
rather fragile and involve a lot of analysis on the full Cartesian product
of both supplier and client side cases of "loophole" to define and verify.

The best way, IMO, is to fix each "loophole"-generating site to use other
operators, as appropriate.  It is at these sites that it is known what
should be done in each case.  I suspect existing intermediate operators
"widen", "insert_mn" and "extract_mn" are sufficient.  Again, another pass
through the cases is indicated.  The only pragmatic drawback to this is
that this requires considerable care and retesting to avoid breakage of
existing behavior.  At worst, it risks inability to bootstrap the compiler.
I would prefer one change at a time, each tested by reboostrapping twice.



On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote:
> Hello:
> Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it".
> Thanks in advance
>
>
>
> El Domingo 13 de diciembre de 2015 21:20, Jay <jay.krell at cornell.edu> escribió:
>
>
> I know, but this pattern is pretty rare.
>
>   - Jay
>
> On Dec 13, 2015, at 1:46 AM, Antony Hosking <hosking at purdue.edu <mailto:hosking at purdue.edu>> wrote:
>
>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.
>> The intent is to allow the backend to avoid that.
>>
>>> On 11 Dec 2015, at 5:53 PM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>>>
>>> The right thing to do, really, is take the address of a float, loophole
>>> that into an address of another type, and dereference that.
>>> Not in the backend, but in the Modula-3 code.
>>>
>>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org