[RFC] .lcomm issue on PowerPC

[Ulrich Weigand]

Hello,

I've run into an issue with .lcomm on PowerPC which I'm not sure how to
best resolve.

The problem is ultimately caused by the fact that the GNU assembler
provides a special implementation of .lcomm for Linux on PowerPC, which
differs from the default implementation on other Linux targets.  The
primary user-visibile difference is that .lcomm on PowerPC supports an
optional alignment argument, while .lcomm on other Linux platforms does
not.

Now, currently LLVM does not understand this difference, and therefore
refuses to accept an alignment argument in its assembler parser.  As it
turns out, it seems some existing assembler code does use this alignment
argument, however, and therefore fails to build with the LLVM assembler
parser.

Now I thought this should be easy to fix by simply setting the
LCOMMDirectiveAlignmentType flag for PowerPC to ByteAlignment.  And this
indeed fixes the assembler parser problem.

However, changing this setting not only affects the assembler parser, but
also the assembler *printer* when LLVM generates assembler source.  This
will now also make use of .lcomm (instead of .local / .comm).  When the
system assembler is the GNU assembler, this now unfortunately runs into a
second problem with its special PowerPC .lcomm implementation: it sometimes
does not work correctly, which results in an assembler error message ("
Error: attempt to move .org backwards").

This is of course a bug in the GNU assembler which we'll need to fix.
However, even once it is fixed in mainline, the installed base of Linux
distributions will have assemblers showing this bug for a long time to
come; it would certainly seem better to avoid forcing everyone to update
their assembler in order to be able to use LLVM.

The solution I'd really prefer would be for LLVM to continue
using .local / .comm when generating assembler source, but to accept .lcomm
(with optional alignment) when parsing assembler source.  Unfortunately,
there is currently no way for the target to specify this particular
combination.

So now my question:
- Do you agree that this should be the prefered solution?
- Would it be acceptable to add a new MCAsmInfo field (maybe called
"UseLCOMMForAsmPrinting" or "HasUsableLCOMMDirective" or ...) to specify
whether the assembler printer ought to use .lcomm, independently of whether
the assembler parser accepts it?

Other suggestions certainly welcome!

Thanks,
Ulrich