[LLVMdev] Issues with inline assembly

Jim Grosbach grosbach at apple.com
Wed Nov 20 17:34:20 PST 2013


On Nov 20, 2013, at 1:26 PM, Stephen Checkoway <s at pahtak.org> wrote:

> 
> On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote:
> 
>> On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote:
>>> 
>>> This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution.
>>> 
>> 
>> Thanks for the link, completely missed when googled the issue. I think
>> no consensus was reached (I cannot find any commit in the repository
>> addressing such issues). I will try and search for the culprit of the
>> inline assembly and replace it with btsl.
>> 
>> As for the issue at hand, although after carefully reading both the
>> thread and re-reading the sections from the instructions set reference
>> it is a rather unpleasant behavior, the error thrown by the toolchain.
>> Since Intel is nowadays by far the biggest vendor for x86/x86_64
>> hardware and they do not mention a single thing about the existence of
>> suffixes for this instruction, it could be accommodated (maybe with a
>> warning though) and take the second option from the 3 you provided.
> 
> One thing to note is that Intel syntax doesn't use suffixes for most (all?) instructions whereas AT&T syntax does. (Although, as I recall, no one actually found an authoritative description of AT&T syntax.) Thus it makes sense that Intel would say nothing about it.

Yup.

There’s not a strong philosophical objection or anything like that to adding aliases for them. As the previous thread indicates, there’s subtleties involved, so it’s important that patches doing something about it are well documented about what they do, don’t do, and why. With that caveat, patches for fixing this would be very welcome.

> 
> 
>> 
>> P.S. : after searching a bit more, it seems that llvm is in fact the
>> only toolchain that rejects/complains about the bts ambiguity, or at
>> least people using llvm get annoyed more easily and start spamming
>> mailing lists :).
> 
> Certainly possible!
> 

If the people using llvm are similar to the people developing it, it’s downright likely! :)

> 
> -- 
> Stephen Checkoway
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20131120/7a7e9369/attachment.html>


More information about the llvm-dev mailing list