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

Thu Mar 30 16:33:21 PDT 2017

I agree, I think you want to do the second thing, where we hook into the
existing variable lookup mechanism and replace it with an immediate operand.

On Mon, Mar 27, 2017 at 3:44 AM, Haroush, Matan <matan.haroush at intel.com>
wrote:

> ping
>
>
>
> *From:* Haroush, Matan
> *Sent:* Tuesday, March 21, 2017 11:02
> *To:* Reid Kleckner <rnk at google.com>
> *Cc:* cfe-dev at lists.llvm.org
> *Subject:* RE: [cfe-dev] [CLANG][X86][inline-asm]Clang support for inline
> assembly MS style
>
>
>
> 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 <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>:
>
>
>
> 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
> 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/20170330/be46e2b2/attachment.html>