llvm dev - Sep 2014 - [LLVMdev] writeNopData and non-instructions in .text

Hi all,
all ELF platforms at least and likely all others too allow something
like the following:

    .text
    .asciz "arbitrary long string"
    .p2align 3

Depending on the size of the string, MCAsmBackend::writeNopData is
called to pad text. For x86 and other backends with byte-sized
instructions, this is no problem. Some backends like ARM and PPC
flush explicitly to 16bit/32bit boundaries. There is an interested
question on whether the non-instructions should be leading or trailing
-- I think the behavior in ARM and PPC is wrong in this regard. The R600
backend seems to be just broken by not writing anything. This leaves
SPARC and Mips. Both currently just return false if the padding is not a
multiply of 32bit and the caller just reports an error.

All this makes me wonder:
(1) Why do we allow the backend to fail at all? Shouldn't the
"pad-with-0" or so behavior be the default?
(2) What is the expected order? Pad to instruction size first or last?

Joerg

On Tue, Sep 16, 2014 at 10:46 PM, Joerg Sonnenberger <
joerg at britannica.bec.de> wrote:
> Hi all,
> all ELF platforms at least and likely all others too allow something
> like the following:
>
>     .text
>     .asciz "arbitrary long string"
>     .p2align 3
>
> Depending on the size of the string, MCAsmBackend::writeNopData is
> called to pad text. For x86 and other backends with byte-sized
> instructions, this is no problem. Some backends like ARM and PPC
> flush explicitly to 16bit/32bit boundaries. There is an interested
> question on whether the non-instructions should be leading or trailing
> -- I think the behavior in ARM and PPC is wrong in this regard.

I am pretty sure I implemented the PowerPC behavior in r191426.

I would be in favor of the following:
1. If the start is aligned *and* the length is aligned, use nops.
2. If the start is aligned but the length is not aligned, insert as many
nops possible but pad out with zero.
3. Otherwise (if the start is misaligned), use *just* zeros.

The R600
> backend seems to be just broken by not writing anything. This leaves
> SPARC and Mips. Both currently just return false if the padding is not a
> multiply of 32bit and the caller just reports an error.
>
> All this makes me wonder:
> (1) Why do we allow the backend to fail at all? Shouldn't the
> "pad-with-0" or so behavior be the default?
> (2) What is the expected order? Pad to instruction size first or last?
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/6bf04575/attachment.html>

On Tue, Sep 16, 2014 at 11:33:13PM -0400, David Majnemer
wrote:
> I would be in favor of the following:
> 1. If the start is aligned *and* the length is aligned, use nops.
> 2. If the start is aligned but the length is not aligned, insert as many
> nops possible but pad out with zero.
> 3. Otherwise (if the start is misaligned), use *just* zeros.
>From reading MCAssembler.cpp, the function is always called before an
aligned place to pad. As such seems the correct behavior is to assume
that end will be aligned and "end - k * instruction size" should be
padded with nops and [start, end - k * instruction size) should be
padded with plain nulls?

Joerg