[llvm-dev] IR inline assembly: the x86 Intel "offset" operator

[Eric Astor via llvm-dev]

Interesting - the patch doesn't address this yet. It looks like we have a
difference (maybe bug?) in how we handle Intel vs. AT&T inline assembly:
https://godbolt.org/z/GQw9ED

Suppose we're expanding an operand with an 'i' constraint, where the
operand is given as, e.g. (i32* @Bar).
If the inline assembly is in Intel dialect, this expands as "Bar" in AT&T
syntax or "dword ptr [Bar]" in Intel syntax.
If the inline assembly is in AT&T dialect, it expands as "$Bar" in AT&T
syntax or "offset Bar" in Intel syntax.

I'd like to try to reconcile this, but I haven't been able to track down
where inline-assembly operands are expanded yet... anyone know where I
should be looking?

On Tue, Dec 10, 2019 at 7:23 PM Reid Kleckner <rnk at google.com> wrote:

> I think perhaps we want to make this LLVM IR asm string:
>   call void asm sideeffect inteldialect "mov eax, $0",
> "i,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* @"?Bar@@3HA") #1, !srcloc !3
>
> The key thing is the 'i' constraint. That ends up producing the wrong
> assembly right now, but maybe with your rebased patch, now it will do the
> right thing.
>
> If you change up the dialect and switch to an ELF triple, this inline asm
> will produce the expected instruction sequence:
>   call void asm sideeffect "movl $0, %eax",
> "i,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* @"?Bar@@3HA") #1, !srcloc !3
> Which is what makes me think this is the way to go.
>
> It's consistent with the AOK_Skip rewrite we do today to skip the "offset"
> text.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191211/ceea4d2f/attachment.html>