[M3devel] Aligned_procedures?

Jay K jayk123 at hotmail.com
Tue Jul 4 09:52:29 CEST 2017


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...)


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


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.


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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20170704/d81cf7bc/attachment.html>


More information about the M3devel mailing list