llvm dev - Dec 2015 - Any way to disable the alignment of functions?

Hi,

I am trying to test if disabling function (entry) alignment has any effect on
performance. On my x86 machine, all functions seem to get aligned to 16-bytes.
I know that GCC provides a flag (-fno-align-functions) to disable function
alignment. However, I could not find the similar flag for clang.
According to the following quote from LLVM doc, clang delegates the job to the
target in case no attributes are specified for a function.

"An explicit alignment may be specified for a function. If not present, or
if the alignment is set to zero, the alignment of the function is set by the
target to whatever it feels convenient.”

So, as a first try, I dived into the “EmitAlignment” code in AsmPrinter.cpp and
simply removed the function alignment part. Interestingly the compilation seems
flawless at many cases (large programs) but on a few programs, it produces a
segfault-generating executable. So my guess is that for some functions,
alignment is necessary for soundness, not just performance.

regards

p.s.

It seems that adding the “OptimizeForSize” attribute to every function causes
that function to be aligned with the minimum alignment required by the target.

> On Dec 27, 2015, at 4:23 PM, Rahman Lavaee Mashhadi <rlavaee at
icloud.com> wrote:
> 
> Hi,
> 
> I am trying to test if disabling function (entry) alignment has any effect
on performance. On my x86 machine, all functions seem to get aligned to
16-bytes.
> I know that GCC provides a flag (-fno-align-functions) to disable function
alignment. However, I could not find the similar flag for clang.
> According to the following quote from LLVM doc, clang delegates the job to
the target in case no attributes are specified for a function.
> 
> "An explicit alignment may be specified for a function. If not
present, or if the alignment is set to zero, the alignment of the function is
set by the target to whatever it feels convenient.”
> 
> So, as a first try, I dived into the “EmitAlignment” code in AsmPrinter.cpp
and simply removed the function alignment part. Interestingly the compilation
seems flawless at many cases (large programs) but on a few programs, it produces
a segfault-generating executable. So my guess is that for some functions,
alignment is necessary for soundness, not just performance.
> 
> regards

On 27 December 2015 at 21:23, Rahman Lavaee Mashhadi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>  but on a few programs, it produces a segfault-generating executable. So
> my guess is that for some functions, alignment is necessary for soundness,
> not just performance.
>
>
> That seems rather odd. On x86, I'm not aware of any instruction
sequence
that REQUIRES alignment of the instruction itself. I'd be interested to see
what code it is that causes this (not that I'll be able to fix it, but just
out of curiosity, and perhaps it will help someone who can fix it...)

As to the original question, does -Os not do what you need?

--
Mats
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151227/9bfcfe48/attachment.html>

On 28 Dec 2015, at 00:24, mats petersson via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 27 December 2015 at 21:23, Rahman Lavaee Mashhadi via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>  but on a few programs, it produces a segfault-generating executable.
So my guess is that for some functions, alignment is necessary for soundness,
not just performance.
> 
> 
> That seems rather odd. On x86, I'm not aware of any instruction
sequence that REQUIRES alignment of the instruction itself.
I would definitely expect it to break most C++ programs, because the C++ ABI
uses the low bit to distinguish between function pointers and pointers to
members.  Other code may also assume that functions start on an n>1 byte
boundary and reuse the low bits for other things.  If a valid function pointer
has its low bit set, then you may end up masking it off in some other code and
then jumping to one byte into the first instruction.  This being x86, that may
still be a valid instruction sequence, but it’s almost certainly not a sensible
one.

David