<div dir="ltr">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: <a href="https://godbolt.org/z/GQw9ED">https://godbolt.org/z/GQw9ED</a><div><br></div><div>Suppose we're expanding an operand with an 'i' constraint, where the operand is given as, e.g. (i32* @Bar).</div><div>If the inline assembly is in Intel dialect, this expands as "Bar" in AT&T syntax or "dword ptr [Bar]" in Intel syntax.</div><div>If the inline assembly is in AT&T dialect, it expands as "$Bar" in AT&T syntax or "offset Bar" in Intel syntax.</div><div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2019 at 7:23 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think perhaps we want to make this LLVM IR asm string:<div>  call void asm sideeffect inteldialect "mov eax, $0", "i,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* @"?Bar@@3HA") #1, !srcloc !3<br></div><div><br></div><div>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.</div><div><br></div><div>If you change up the dialect and switch to an ELF triple, this inline asm will produce the expected instruction sequence:</div><div>  call void asm sideeffect "movl $0, %eax", "i,~{eax},~{dirflag},~{fpsr},~{flags}"(i32* @"?Bar@@3HA") #1, !srcloc !3</div><div>Which is what makes me think this is the way to go.</div><div><br></div><div>It's consistent with the AOK_Skip rewrite we do today to skip the "offset" text.</div></div>
</blockquote></div>