<!-- This file has been automatically generated. See web/README.md -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div id="compose-container" style="direction: ltr" itemscope="" itemtype="https://schema.org/EmailMessage">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name" content="Outlook Mobile for iOS"></span></span>
<div>
<div><br>
</div>
<div><br>
</div>
<div class="acompli_signature">- Jay</div>
<div class="gmail_quote">_____________________________<br>
From: Rodney M. Bates <<a dir="ltr" href="mailto:rodney_bates@lcwb.coop" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">rodney_bates@lcwb.coop</a>><br>
Sent: Wednesday, July 5, 2017 12:24 PM<br>
Subject: Re: [M3devel] Aligned_procedures?<br>
To: <<a dir="ltr" href="mailto:m3devel@elegosoft.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">m3devel@elegosoft.com</a>><br>
<br>
1. Because we are not allowed to store function pointers, lest they are closures, and become stale?</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">2. I might have made a mistake: 32 bit targets mights also be true.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">3. The rationale is a little confusing because there are multiple factors. </div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">The factors are the alignment of normal functions and the alignment requirements of the architecture to read an INTEGER (which I suggest should be instead a 4 byte integer at least on most architectures, in this
context).</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">The generated code reads an integer from a function pointer, compares to -1. It assumes -1 can't be a valid instruction, at least as the first in a function. This is of dubious portability both because -1 is
not well known to me as invalid code, and because not all systems allow reading code bytes.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">If -1, it is assumed to be a closure and reads the function pointer and static link from the subsequent words.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">The "problem" is that, closures are guaranteed to be at least word-aligned, and the read to check for -1 guaranteed not to trigger an alignment fault. But, on some systems, other function pointers have no such
alignment guarantee.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">So an alignment check is optionally inserted to avoid the alignment fault.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">We could also unconditionally insert the alignment check. It is never wrong. It is code bloat if not needed but arguably it is a nice optimization.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">We could also leave the choice to the backend.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">x86/amd64 have no alignment requirement for integers or instructions or functions. So the check is not needed.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">PowerPC, MIPS, Alpha, Sparc, arm64 I believe all have fixed size 4 byte 4-aligned instructions. Reading a 4 byte integer should be ok, unconditionally through a function pointer, but not an 8 byte integer.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">Arm32 is wierd. I believe instructions are either 2 or 4 bytes, and aligned to only 2?? The low bit indicates the size: 0 for 4, 1 for 2. The alignment check is needed, or clear</div>
<div class="gmail_quote" style="direction: ltr;">the low 2 bits and read.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">Clear the low bits and read is also a portable approach.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">IA64 bundles up to 3 instructions in 128 bits with..41 bits per instruction and 5 bit template. I don't know their alignment.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote" style="direction: ltr;">I haven't been able to think of another solution, that doesn't use runtime codegen..until recently, but the other solution I know of..generates closures slowly and with OS and processor porting work.</div>
<div class="gmail_quote" style="direction: ltr;"> </div>
<div class="gmail_quote" style="direction: ltr;"> - Jay</div>
<div class="gmail_quote" style="direction: ltr;"><br>
On 07/04/2017 02:52 AM, Jay K wrote:<br>
> Aligned_procedures<br>
><br>
><br>
> I'm sure I've mentioned this before...but I'm clearing out my backlog of lingering diffs.<br>
><br>
><br>
> In my bid to make more of the targets look more the same,<br>
> I suggest making Aligned_procedures always be false.<br>
><br>
><br>
> This slightly pessimises mainstream targets: x86 and amd64.<br>
><br>
><br>
> I believe it slightly bloats all calls through function pointers.<br>
> (including object methods? Maybe, but I don't think those can be closures,<br>
> so that could/should be fixed -- though the idea of a method being a closure<br>
> is a good one...)<br>
><br>
<br>
Only calls through a formal parameter of procedure type (not a variable, field, etc.)<br>
and assignments other than passing things to a VALUE or READONLY formal need to do a<br>
closure-check. Other cases just use/copy the pointer value.<br>
<br>
><br>
> It has no affect on PowerPC, ARM, SPARC, MIPS, Alpha, etc. -- 32bit or 64bit.<br>
><br>
<br>
Is this because these targets require all procedures to be have the same alignment as<br>
integer anyway? So code is always as if Aligned_procedures were true, i.e., no<br>
alignment check is ever necessary?<br>
<br>
><br>
> I believe the difference is that when calling a function pointer, on x86/amd64,<br>
> we just read it for a pointer-size integer, and compare to -1.<br>
><br>
><br>
> If Aligned_procedures is left as always false, that check would first<br>
> see if the pointer is aligned on a pointer-size, and if not, skip the check for -1.<br>
><br>
><br>
> This is because most architectures will issue an alignment fault for the<br>
> unaligned read, and we know such unaligned values are not closures.<br>
> x86/amd64 do not care much about alignment.<br>
><br>
><br>
> I have proposed, somewhat the opposite, that this check actually be always be 4 bytes,<br>
> not a full pointer. That would likely allow it to always be TRUE. Closures would still<br>
> be pointer-aligned, but we'd only check for 4 bytes -1 instead of a full pointer.<br>
><br>
> The idea is that all functions are 4-aligned on all targets that care about integer alignment.<br>
> Even if they aren't 8-aligned on 64bit targets.<br>
><br>
<br>
So no alignment check is ever required. We still have to pad function starts<br>
to 4-bytes. I would call this Aligned_procedures=true on32-bit targets and 64-bit<br>
targets that do not otherwise require 8-byte alignment of functions, and somewhere<br>
partway between false and true for 64-bit targets that do not otherwise require<br>
8-byte alignment of functions, since functions are only partially aligned, and still<br>
no alignment check is required.<br>
<br>
We did once have the discussion whether there exists or could someday exist, a target<br>
where 4 bytes or 8 bytes of all one-bits would be valid machine code at the<br>
start of a function, or anywhere at all. The only conclusion I recall is that it<br>
is unlikely. But this scheme would be slightly weaker in this regard in that it<br>
would take a mere 4 bytes of -1 as valid code, to be mistaken for a closure.<br>
<br>
><br>
> I believe that would not work for ARM32-Thumb and I can't bring myself to rule<br>
> out such targets.<br>
><br>
<br>
What are the relevant properties of ARM32-Thumb?<br>
<br>
><br>
> Another option would be to make this only be for the C backend.<br>
><br>
> It isn't clearly useful given the gcc backend -- unless maybe redistributing<br>
> same IR across multiple targets.<br>
><br>
> - Jay<br>
><br>
><br>
<br>
I like the idea of just unconditionally integer-aligning all procedures on all<br>
targets. No runtime alignment check would ever be necessary, reducing the time<br>
bloat, at the cost of extra code size bloat on those targets where aligning every<br>
procedure would not otherwise be required. I like that size/time tradeoff better.<br>
<br>
The code sequence for closure checks looks pretty gross right now. It is<br>
poorly optimized. I have looked at improving it, but some combination of the<br>
alignment check, the nil check, and the -1 check are produced at nicely-abstracted<br>
different places in CG that don't know about each other, so it would take some rework<br>
to do it. Maybe even a raised-level CG IR operator "closure_check".<br>
<br>
Actually, the unaligned checks increase code size as well as execution time for<br>
closure checks, which could partially compensate or even overcompensate for the<br>
alignment padding. OTOH, probably many programs have no cases that require closure<br>
checks at all, so for those, it would be pure size loss for the extra alignment pad<br>
bytes.<br>
<br>
<br>
><br>
> _______________________________________________<br>
> M3devel mailing list<br>
> <a dir="ltr" href="mailto:M3devel@elegosoft.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">
M3devel@elegosoft.com</a><br>
> <a dir="ltr" href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="4">
https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br>
><br>
<br>
-- <br>
Rodney Bates<br>
<a dir="ltr" href="mailto:rodney.m.bates@acm.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5">rodney.m.bates@acm.org</a><br>
_______________________________________________<br>
M3devel mailing list<br>
<a dir="ltr" href="mailto:M3devel@elegosoft.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">M3devel@elegosoft.com</a><br>
<a dir="ltr" href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="7">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br>
<br>
<br>
</div>
</div>
</div>
</body>
</html>