[LLVMdev] LLVM fails for inline asm with Link Time Optimization

[Ashish Saxena]

Even when I am passing -mllvm --x86-asm-syntax=intel to clang++.exe the
assembly is generated in AT&T syntax. When can this happen ?

On Fri, Mar 27, 2015 at 11:25 PM, Ashish Saxena <ashishcseitbhu at gmail.com>
wrote:

> It is failing at link time . Examples are what I have given above. There
> is an compiler option -mllvm --x86-asm-syntax=intel. Is there something
> similar for linker which I can provide via -plugin-opt ?
>
> On Fri, Mar 27, 2015 at 9:31 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> At which stage is this failing? Can you provide an example and commands?
>>
>> Looks like the information about the use of intel syntax is being
>> dropped along the way.
>>
>> On 27 March 2015 at 11:40, Ashish Saxena <ashishcseitbhu at gmail.com>
>> wrote:
>> > Ah , I thought that there is issue while parsing inline asm in function
>> > bodies , here are some of instruction where it cribs . Can you make out
>> > something of it ?
>> >
>> > I am going to try out -no-integrated-as option . Not sure if it will
>> help ?
>> >
>> > LLVM ERROR: Error parsing inline asm
>> >
>> > 1><inline asm>:1:17 : error 0: unexpected token in argument list
>> >
>> > 1>        mov ebx, dword ptr 16(%esp)
>> >
>> > 1>                       ^
>> >
>> > 1><inline asm>:2:17 : error 0: unexpected token in argument list
>> >
>> > 1>        mov edi, dword ptr 24(%esp)
>> >
>> > 1>                       ^
>> >
>> > 1><inline asm>:3:17 : error 0: unexpected token in argument list
>> >
>> > 1>        mov esi, dword ptr 28(%esp)
>> >
>> > 1>                       ^
>> >
>> > 1><inline asm>:4:21 : error 0: invalid token in expression
>> >
>> > 1>        movq mm1, [edi+ebx-$8]
>> >
>> > 1>                           ^
>> >
>> > 1><inline asm>:5:12 : error 0: invalid operand for instruction
>> >
>> > 1>        pxor mm0, mm0
>> >
>> >
>> > Thanks
>> >
>> > Ashish
>> >
>> >
>> > On Fri, Mar 27, 2015 at 8:21 PM, Rafael Espíndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>
>> >> If you are getting a parse error it is very likely a different bug. In
>> >> that bug the issue is that we don't parse the function bodies to find
>> >> if some inline in them defines (or uses) a given symbol.
>> >>
>> >> On 26 March 2015 at 13:30, Ashish Saxena <ashishcseitbhu at gmail.com>
>> wrote:
>> >> > Thanks for response Francois . Do you have any pointers on what can
>> be
>> >> > the
>> >> > issue here or something I can try out. I saw similar active bug in
>> llvm
>> >> > database
>> >> >
>> >> > https://llvm.org/bugs/show_bug.cgi?id=5623
>> >> >
>> >> > Thanks
>> >> > Ashish
>> >> >
>> >> > On Thu, Mar 26, 2015 at 10:52 PM, Francois Pichet <
>> pichet2000 at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Mar 25, 2015 at 4:47 PM, Ashish Saxena
>> >> >> <ashishcseitbhu at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi ,
>> >> >>>     I am trying to enable link time optimization for my projects.
>> Few
>> >> >>> of
>> >> >>> them has inline assembly which works perfectly with clang/llvm but
>> on
>> >> >>> enabling LTO I get following error
>> >> >>>
>> >> >>> LLVM ERROR: Error parsing inline asm
>> >> >>>
>> >> >>> <inline asm>:103:2 : error 0: unknown use of instruction mnemonic
>> >> >>> without
>> >> >>> a size suffix
>> >> >>> <inline asm>:104:16 : error 0: invalid operand for instruction
>> >> >>> <inline asm>:106:17 : error 0: unexpected token in argument list
>> >> >>>
>> >> >>> & so on
>> >> >>>
>> >> >>> Is this a known issue ? Any workaround for this ?
>> >> >>
>> >> >>
>> >> >>
>> >> >> My experience is that LTO doesn't break inline assembly.
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > LLVM Developers mailing list
>> >> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >> >
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150328/af87a9bc/attachment.html>