llvm dev - Dec 2019 - IR inline assembly: the x86 Intel "offset" operator

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>

On Wed, Dec 11, 2019 at 9:45 AM Eric Astor <epastor at google.com> wrote:
> 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.
>
That sounds right.

> 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?
>
I'm pretty sure this is llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191211/4788678a/attachment.html>

That did it: issue was in X86AsmPrinter::PrintOperand, which emitted a
prefix of "$" when printing an address operand in AT&T syntax...
but didn't
add the prefix "offset " when in Intel syntax.

Still need to get clang to emit the operand with the "i" constraint,
but
now at least I know what success will look like.

On Wed, Dec 11, 2019 at 2:32 PM Reid Kleckner <rnk at google.com> wrote:
> On Wed, Dec 11, 2019 at 9:45 AM Eric Astor <epastor at google.com>
wrote:
>
>> 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.
>>
>
> That sounds right.
>
>
>> 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?
>>
>
> I'm pretty sure this is
> llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp.
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191211/0a0de9d7/attachment.html>