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

[Rodney M. Bates]

The further I get into this, the more worms crawl out.  The only cm3 IR
operators that change an operand size (without storing/refetching in memory)
are widen and chop.  The inserts and extracts work entirely within the same-
sized word.  But widen and chop are never produced by the front end, and
the integrated and C back ends assert they don't happen.  m3cc has code
for them, but this will be entirely untested, and vetting it involves
tracing through lots of gcc code.

So I plan to redefine the misdocumented loophole operator to allow size
changes among Int32/Word32/Int64/Word64, with shortening changes doing a
chop and widening doing either zero-extend or sign-extend, consistent with
the signedness of the result type.  I think this will cover all the cases
required by current places where loophole is emitted, which further implies
the backends are all doing at least these, assuming there are sufficient
test cases.  This amounts only to correcting the documentation in M3CG_Ops.i3

m3llvm will then need to add these behaviors, and things should at least work
as well as always.

The many loophole-emitting places still need thorough review and documentation
of their requirements.  Some of them assume address is same size as native
integer.

Implementing chop and widen, using them for size changes, and changing loophole
back to the same as LOOPHOLE is the right way, but involves a lot of work and
testing, for small code changes.

On 12/16/2015 12:01 PM, Rodney M. Bates wrote:
> 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