[llvm-commits] [PATCH/RFC] Only use .lcomm if it supports alignment

[Benjamin Kramer]

On 27.11.2012, at 15:05, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> 
> Hello,
> 
> on some platforms, the assembler supports a ".lcomm" directive to create a
> local common (BSS) variable.  Unfortunately, this is implemented
> differently across platforms: on some platforms, .lcomm supports a
> user-specified alignment argument, on others it does not.  Where the
> alignment argument is not supported (or not specified), the assembler will
> assume a default alignment requirement derived from the variable size in a
> platform-specific manner.
> 
> When using an external assembler, LLVM will always use .lcomm on platforms
> where the alignment argument is supported (and always pass what LLVM
> considers the variable's alignment).  However, on platforms where the
> alignment argument is not supported (which unfortunately include ELF), it
> is not valid in general to use .lcomm.  LLVM currently does so for
> variables that have no alignment requirement.  This is clearly always
> *correct*, no matter what the platform-specific details of .lcomm alignment
> are.
> 
> However, if we want LLVM to always produce the same binary with the
> integrated assembler as it does with the external one, this is still a
> problem: if LLVM considers the variable to have no alignment requirement,
> the integrated assembler will enforce no alignment requirement, but simply
> place the variable at the next free address.  However, the external
> assembler *may* implement *some* alignment requirement it has derived (in a
> platform-specific manner) from the .lcomm size.  This means it may actually
> add padding bytes before the variable -- resulting in a different binary.
> 
> Now one way to fix this would be for the LLVM to exactly emulate the
> alignment behaviour of .lcomm on each given target, and only use .lcomm if
> the variable's actual alignment requirement matches what the .lcomm
> algorithm would derive.  However, this seems tedious and error-prone, and
> probably not actually very useful.  Note that in cases where .lcomm cannot
> be used, LLVM already falls back to issuing a pair of .local and .comm
> directives, which always allows to specify the precise alignment
> requirement, and has otherwise the same effect as .lcomm.
> 
> Thus, it would appear to me that the simplest fix would be to simply never
> use .lcomm and always fall back to .local / .comm on targets where .lcomm
> does not support an alignment argument.  The attached patch implements
> this.  (Note that two tests need to be modified to check for the new
> behaviour instead of the old one.)
> 
> Tested on powerpc64-linux with no regression; with this patch, the
> integrated and the external assembler produce 100% identical data sections
> (.data, .bss, .rodata ...) on all objects in test-suite.  (There are still
> differences in .eh_frame and debug sections.)
> 
> OK to commit?

LGTM!

- Ben
> 
> Bye,
> Ulrich
> 
> (See attached file: diff-llvm-lcomm)<diff-llvm-lcomm>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits