Re: [PATCH] D12399: Microsoft compatibility – add support for “relaxation” of memory operands in inline assembly.

Reid Kleckner via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 11 10:18:53 PST 2015


On Wed, Nov 11, 2015 at 7:36 AM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 11 November 2015 at 07:03, michael zuckerman
> <michael.zuckerman at intel.com> wrote:
> > I am not familiar with any libraries that contain these “relaxations”.
> Never the less Microsoft supports these “relaxations”. If we want LLVM to
> be compatible with Microsoft like GAS, we need to add this feature.
>
> Our compatibility with GAS isn't absolute either. For example we've
> taken a conscious decision on ARM not to actively support the legacy
> assembly syntax.
>
> > I don’t think that “just tell users to fix their code” is the correct
> approach
>
> Like Reid, I do.
>

Our compatibility policy used to draw the line at whatever is necessary to
parse system headers, and we included all MS SDK headers in this category.
I've argued that we should expand it a little bit to include popular
cargo-culted idioms of the platform to help ease the burden of transition
for our users. It's not clear to me that the invalid code you are trying to
accept is widespread.

What would change my mind is evidence that it is widespread:
- Inline assembly with this problem is in windows.h or some other Microsoft
SDK headers (DirectX, ATL, whatever)
- Multiple popular open source projects that rely on this functionality
(say, Boost, ffmpeg, etc)

There's lots of other open issues that you can work on that will actually
help users in a meaningful way. Yesterday I ran into code like this that
does not compile:
struct A {
  void f() {
    __asm mov eax, this
    // error: expected unqualified-id
  }
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151111/eead70f5/attachment.html>


More information about the llvm-commits mailing list