[llvm-dev] File/module scope inline assembly

[ORiordan, Martin via llvm-dev]

I am trying to support an experimental DSL that uses non-C identifiers, but I want to write the implementation of the runtime support libraries for this DSL in C.  The compiler is built using the LLVM v5.0.0 release branch.

To do this I thought I could simply write:

int foo() { return 42; }     // The C implementation
asm(".alias nonCname foo");  // Make the non-C name be a synonym for the C implementation

If I compile with '-S -emit-llvm', the LL file contains:

module asm ".alias nonCname foo"
define i32 @foo() local_unnamed_addr #0 {
  ret i32 42
}

That is, the inline-assembly precedes the function definition.  The resulting assembly code for the target also has the '.alias nonCname foo' before the definition for the function 'foo'.  When I edit the LL file to place the inline-assembly after the function definition, it makes no difference to the emitted assembly code for the target, it is still placed first.

Our assembler requires that the symbol being aliased has been defined before the '.alias' directive; but I can't get LLVM to do this, and it aggregates all file-scoped (or module-scoped) inline assembly before the code generated for the functions and data.

Since the semantics of inline-assembly are very murky, I don't know if this is a bug or by-design.

Is there anyway of writing C code that will preserve the relative ordering of file-scoped function, data and inline-assembly definitions?

Thanks,

            MartinO


--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/263e9f37/attachment.html>