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

[Kristof Beyls]

I agree that this pseudo instruction should be supported.

 

>From having talked with a number of people very experienced in writing
assembler for ARM targets,
they consistently find this one of the most important features missing in
the integrated assembler.

 

Kristof

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chris Lattner
Sent: 27 October 2013 01:02
To: Sean Silva
Cc: LLVM Dev
Subject: Re: [LLVMdev] Add support for ldr pseudo instruction in ARM
integrated assembler

 

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.

 

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/20131027/8ddb7f14/attachment.html>