[LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler

[Sean Silva]

On Tue, Oct 29, 2013 at 1:21 PM, Jim Grosbach <grosbach at apple.com> wrote:

>
> On Oct 26, 2013, at 5:02 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 25, 2013, at 5:22 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
> I’m not sure macros are a good analogy, but there are other
>> pseudo-instructions that we’re not always able to reconstruct in
>> disassembled code back to how the user wrote them. Or if we do, it’s purely
>> via heuristic methods. I don’t see this as a big issue.
>>
>
> I agree.  These pseudo instructions seem like pure syntactic sugar that
> should never be produced by the disassembler.  That doesn't make them bad,
> in fact it makes them simpler to implement and reason about.
>
>
>> Do the ARM usages include allowing a single pseudo-instruction to expand
>> to multiple real instructions? For example, a movw/movt pair? If so, I’m
>> *very* opposed to that part.
>>
>
> Why?  For people writing assembly manually, having pseudo instructions to
> encapsulate common patterns is very useful.
>
>
> An assembler is not a compiler. When reading the assembly code, it should
> be clear what instructions are actually going into the output.
>

This is mostly true in the case of kernel code when you're writing in
assembler because of 1) extreme constraints that you can't really work with
from C (e.g. no stack available, need to avoid touching certain registers,
etc.) or 2) Need access to special instructions.

However, it is definitely not the case when the purpose of writing assembly
code is in order to generate extremely high performance code, where
essentially the assembler *is* used as a sort of domain-specific compiler
(this is why basically all quality assemblers have powerful macro systems
(I believe many are turing-complete, actually)). There is also a
portability aspect where roughly the same code works for multiple targets,
with minor variations. For example, check out these from x264 (a video
encoder, and one of the most highly optimized programs in existence):

"domain-specific compiler":
http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86inc.asm;h=ef45a2905bd8e3d920aa74d23a32fc0c169d9a57;hb=HEAD#l881

http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86inc.asm;h=ef45a2905bd8e3d920aa74d23a32fc0c169d9a57;hb=HEAD#l590

http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/dct-64.asm;h=c1aff843101f0081686f07ebe04908c7aa803e4a;hb=HEAD#l394

"portability":
http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86inc.asm;h=ef45a2905bd8e3d920aa74d23a32fc0c169d9a57;hb=HEAD#l88


-- Sean Silva


>
> A single assembler instruction, pseudo or otherwise, should represent a
>> single instruction in the final output. Even with a single instruction, I’m
>> still leery, as it makes the source unclear whether a constant load is a
>> plain ‘move’ instruction or a memory reference. That makes it very
>> difficult to read the assembly and do any sort of thinking about
>> performance considerations.
>>
>
> No one is compelled to use these if they don't want to.
>
> x86 has this issue to an extent that goes far beyond what you describe
> here, and FWIW I've never seen a situation where it has been a problem.
> Usually when doing instruction-level/uarch-level optimization I find myself
> disassembling raw bytes in memory or in linked executables (or showing
> relocations in object files). The point of source code (even assembler) is
> to abstract over what is happening in the machine; when you specifically
> want to know what is happening in the machine you should use a tool
> designed to show you that, i.e. a disassembler (that shows raw bytes too).
>
> Also, I think the fact that there are high-profile users (well, I guess
> they are potential users since this is currently broken) that use this
> feature overrides any "elegance"/"simplicity" concern about an instruction
> expanding differently, for the purposes of "is it acceptable to support
> this feature in LLVM if someone will do the work to implement and maintain
> it?".
>
>
> Given that this pseudo instruction is widely implemented and empirically
> used by important code bases like the Linux kernel, it seems like a
> no-brainer to support it IMO.
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131031/91dbeeed/attachment.html>