[cfe-dev] [CLANG][X86][inline-asm]Clang support for inline assembly MS style

Tue Mar 21 02:01:56 PDT 2017

After further investigation we have 2 viable locations to be considered for the final design as described below,
I’d would like to bring this up for debate, any insight you may have to offer regarding the recommended approach would be appreciated.

1.       Handle before buildMSAsmString takes the AsmTokens vector (the tokens are parsed by clang fe, buildMSAsmString is called to create the string buffer on which the AsmParser is called).

In this approach we can iterate over AsmTokens, look up each identifier token and replace tokens which refer to ConstEnumDecl with their constant value.

a.       This is target independent.

b.      Handling is similar handle to macro constants.

c.       We can reuse ParseMSAsmIdentifier

·         We also effectively parse the assembly string twice, thus we need to ignore any possible duplicate diagnostics (i.e. turn off temporarily).

·         This solution was able to pass lit tests.

d.      However this forces us to check each and every identifier in AsmToks vector, since clang does not know how to differentiate operands from instructions or any other identifier tokens.

2.       Handle in X86AsmParser - when the target parser iterates over each of the instructions in the asm string and construct the IR inline asm string.

a.       This is target dependent

b.      Handling is similar to variable operands, we can exercise one of two options:

                                                               i.      Adding an input attribute to the IR string (i32 <const_val>) paired with replacing the identifier with $<reference_number>  similarly to how GCC extended asm works.

GCC extended asm In ATT dialect is transformed as follows:

asm("movl %0 + 1*3,%%eax" : :"i"(A)) ---- > call void asm sideeffect "movl $0 + 1*3,%eax", "i,~{dirflag},~{fpsr},~{flags}"(i32 12)….” // where A is an enum constant with val =12

For MS style inline asm we would want to generate:

asm("mov eax ,A + 1*3") ---- > call void asm sideeffect inteldialect " mov eax ,$0 + 1*3 ", "i,~{dirflag},~{fpsr},~{flags}"(i32 12)….”

                                                             ii.      Using the AsmRewrite mechanism to replace the identifier directly w/o folding the expression.
asm("mov eax ,A + 1*3") ---- > call void asm sideeffect inteldialect " mov eax ,$12 + 1*3 ", "~{dirflag},~{fpsr},~{flags}"….”

c.       Normally the second pass of the X86AsmParser compress any remaining arithmetic expressions into a canonical form resulting in a legal instruction.

From my perspective it seems that the second option is slightly more natural despite being target specific, since it seems like the general design behaves in a similar fashion.
Feel free to contact me if any clarification is needed.

since this is where identifiers for variables are resolved and transformed.

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Wednesday, December 07, 2016 19:03
To: Haroush, Matan <matan.haroush at intel.com>
Cc: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] [CLANG][X86][inline-asm]Clang support for inline assembly MS style

We should probably rewrite enums in the frontend into integer constants. I guess the fix would live in buildMSAsmString.

2016-12-05 7:38 GMT-08:00 Haroush, Matan via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>:

Hey
I’m working on adding support for inline asm to LLVM.org.
I am trying to determine what is the best place to insert code to enable use of enumerated constants
when using Microsoft style inline asm in a similar fashion to the way macros are used.

EXAMPLE:
########################################################################################################
C code:

int test_inline_asm_enum() {
    enum { A = 12, B};                        // can also be declared globally
                __asm mov ax, A
    return B;
}

Generated LLVM IR:

define i32 @test_inline_asm_enum() #0 {
entry:
call void asm sideeffect inteldialect                                                                          \
"mov ax, qword ptr A",   "~{dirflag},~{fpsr},~{flags}"() #1, !srcloc !1
ret i32 13
}

COMPILE LINE:

Clang -cc1 -fasm-blocks -O0 -emit-llvm <codefile.c> -o -

* without –emit-llvm flag the compiler will crash as it tries to handles A like a variable.
** note the absence of an allocation of A before the function call, this is because enums are
not emitted to IR but treated as integer constants.

########################################################################################################

After some investigation I narrowed the scope to two locations in clang which are reasonable candidates:

1.       buildMsAsmString – where macros are handled

2.       asmParser/X86 AsmParser which handles the assembly semantics and emits the IR.

My main issue though is to determine if the token/identifier belongs to an EnumConstDecl/Expr.
I’ve noticed the code in this area uses a lookup method which is called via parser->semaCallback.
However I don’t really understand yet how to create an instance of such a handler in order to lookup
previously declared labels(particularly EnumConstantDecls).

I was hoping that someone may have some insight to share regarding the problem or on lookup usage in general.
Please let me know if you need any clarifications and feel free to contact me via mail.
Thanks,

Matan Haroush

---------------------------------------------------------------------
Intel Israel (74) Limited

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.

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

---------------------------------------------------------------------
Intel Israel (74) Limited

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/cfe-dev/attachments/20170321/1c46168e/attachment.html>