[M3devel] Aligned_procedures?

[Rodney M. Bates]

On 07/04/2017 02:52 AM, Jay K wrote:
> Aligned_procedures
>
>
> I'm sure I've mentioned this before...but I'm clearing out my backlog of lingering diffs.
>
>
> In my bid to make more of the targets look more the same,
> I suggest making Aligned_procedures always be false.
>
>
> This slightly pessimises mainstream targets: x86 and amd64.
>
>
> I believe it slightly bloats all calls through function pointers.
>   (including object methods? Maybe, but I don't think those can be closures,
>   so that could/should be fixed -- though the idea of a method being a closure
>   is a good one...)
>

Only calls through a formal parameter of procedure type (not a variable, field, etc.)
and assignments other than passing things to a VALUE or READONLY formal need to do a
closure-check.  Other cases just use/copy the pointer value.

>
> It has no affect on PowerPC, ARM, SPARC, MIPS, Alpha, etc. -- 32bit or 64bit.
>

Is this because these targets require all procedures to be have the same alignment as
integer anyway?  So code is always as if Aligned_procedures were true, i.e., no
alignment check is ever necessary?

>
> I believe the difference is that when calling a function pointer, on x86/amd64,
> we just read it for a pointer-size integer, and compare to -1.
>
>
> If Aligned_procedures is left as always false, that check would first
> see if the pointer is aligned on a pointer-size, and if not, skip the check for -1.
>
>
> This is because most architectures will issue an alignment fault for the
> unaligned read, and we know such unaligned values are not closures.
> x86/amd64 do not care much about alignment.
>
>
> I have proposed, somewhat the opposite, that this check actually be always be 4 bytes,
> not a full pointer. That would likely allow it to always be TRUE. Closures would still
> be pointer-aligned, but we'd only check for 4 bytes -1 instead of a full pointer.
>
> The idea is that all functions are 4-aligned on all targets that care about integer alignment.
> Even if they aren't 8-aligned on 64bit targets.
>

So no alignment check is ever required.  We still have to pad function starts
to 4-bytes.  I would call this Aligned_procedures=true on32-bit targets and 64-bit
targets that do not otherwise require 8-byte alignment of functions, and somewhere
partway between false and true for 64-bit targets that do not otherwise require
8-byte alignment of functions, since functions are only partially aligned, and still
no alignment check is required.

We did once have the discussion whether there exists or could someday exist, a target
where 4 bytes or 8 bytes of all one-bits would be valid machine code at the
start of a function, or anywhere at all.  The only conclusion I recall is that it
is unlikely.  But this scheme would be slightly weaker in this regard in that it
would take a mere 4 bytes of -1 as valid code, to be mistaken for a closure.

>
> I believe that would not work for ARM32-Thumb and I can't bring myself to rule
> out such targets.
>

What are the relevant properties of ARM32-Thumb?

>
> Another option would be to make this only be for the C backend.
>
> It isn't clearly useful given the gcc backend -- unless maybe redistributing
> same IR across multiple targets.
>
>    - Jay
>
>

I like the idea of just unconditionally integer-aligning all procedures on all
targets.  No runtime alignment check would ever be necessary, reducing the time
bloat, at the cost of extra code size bloat on those targets where aligning every
procedure would not otherwise be required.  I like that size/time tradeoff better.

The code sequence for closure checks looks pretty gross right now.  It is
poorly optimized.  I have looked at improving it, but some combination of the
alignment check, the nil check, and the -1 check are produced at nicely-abstracted
different places in CG that don't know about each other, so it would take some rework
to do it.  Maybe even a raised-level CG IR operator "closure_check".

Actually, the unaligned checks increase code size as well as execution time for
closure checks, which could partially compensate or even overcompensate for the
alignment padding.  OTOH, probably many programs have no cases that require closure
checks at all, so for those, it would be pure size loss for the extra alignment pad
bytes.


>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

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