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

[Jay K]

 > Some of them assume address is same size as native integer. 
 
 This is correct and by-design. 
    BYTESIZE(INTEGER) = BYTESIZE(REFANY) etc. (all pointers are the same size)   
 
 In C and C++, for the vast majority of systems 
      sizeof(size_t) = sizeof(char*) etc. (again, all pointers are the same size)  
 
  VMS64 might be an exception. Might. 
 
  However modern C and C++ offer intptr_t/uintptr_t for this: 
    sizeof(intptr_t) == sizeof(char*) etc. (again, all pointers are the same size)  
 
 
  It is popular to think sizeof(long) == sizeof(char*) but that is frequently incorrect, maybe half the time.   
  (i.e. on Win64 and maybe VMS64) 
 
 
 I'd still like to check/test what happens in the C and NT386 backends here, for loophole changing sizes, but not right now, sorry.
 
 
The asserts about widen/chop not occurring are from me.
You know, I fairly recently went through much/most/all of what you are doing (I hope all, but I fear much/most) -- implementing a new backend from scratch, and having to figure out precise meanings of things
 
> > I would prefer one change at a time, each tested by reboostrapping twice.
 
 
upgrade.py does the "twice" part builtin.
 
 
 - Jay

 
> Date: Sat, 2 Jan 2016 15:03:27 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?)
> 
> 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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160103/440ffbf5/attachment-0002.html>