<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 4, 2017 at 11:55 AM, Johan Engelen <span dir="ltr"><<a href="mailto:jbc.engelen@gmail.com" target="_blank">jbc.engelen@gmail.com</a>></span> wrote:<br><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br></span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_6752786629140815920gmail-">2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
> The error is gone after removing (or reducing) the alignment of `%a`. This<br>
> makes me believe that our inline asm syntax is correct to add an offset to a<br>
> pointer: " 4+$0 ".<br>
<br>
</span>The AT&T syntax for a displaced address doesn't have the '+'; it's<br>
just "4(%rsp)" so you should change the IR to "4$0".<br>
<br>
LLVM appears to be optimizing the addressing mode, and the optimizer<br>
is being more lenient on this detail so you're getting lucky when the<br>
+4 can be combined with an existing %rsp offset.</blockquote><div><br></div></span><div>Things break down when part of the offset is a linktime constant:</div><div><br></div><div>...</div><div><br></div><div>So depending on the pointer argument, I need to write a + or without +, complicating automatic codegen.</div></div></div></div></blockquote><div><br></div><div>The problem is worse. The following code is accepted depending on PIC or non-PIC compilation:</div><div><br></div><div>```</div><div><div><font face="monospace, monospace">source_filename = "asanasm.d"</font></div><div><font face="monospace, monospace">target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"</font></div><div><font face="monospace, monospace">target triple = "x86_64-linux-gnu"</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">@_D7asanasm9constantsG2k = global [2 x i32] [i32 66051, i32 66051]</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">define void @_D7asanasm8offconstFZv() {</font></div><div><font face="monospace, monospace">  call void asm sideeffect "movdqa 4$0, %xmm7", "*m,~{xmm7}"([2 x i32]* @_D7asanasm9constantsG2k)</font></div><div><font face="monospace, monospace">  ret void</font></div><div><font face="monospace, monospace">}</font></div></div><div>```</div><div><br></div><div>I get no errors with PIC:</div><div><font face="monospace, monospace">> llc test.ll -o test.s -O0 -relocation-model=pic<br></font></div><div>The asm output:</div><div><div><font face="monospace, monospace">  movq    _D7asanasm9constantsG2k@GOTPCREL(%rip), %rax</font></div><div><font face="monospace, monospace">  #InlineASM</font></div><div><font face="monospace, monospace">  movdqa  4(%rax), %xmm7</font></div></div><div><br></div><div><br></div><div>But without PIC:</div><div><div><font face="monospace, monospace">> llc test.ll -o test.s -O0 -relocation-model=static</font></div><div><font face="monospace, monospace"><inline asm>:1:10: error: unexpected token in argument list</font></div><div><font face="monospace, monospace">        movdqa 4_D7asanasm9constantsG2k(%rip), %xmm7</font></div></div><div><font face="monospace, monospace">                ^</font></div><div><br></div><div>So it appears that applying an offset to a pointer variable will break using either "4+$0" or "4$0", and you have to be lucky to guess correctly what's going to happen with the pointer argument passed into the inline asm call. (my problem would be solved when "4+$0" would always be accepted)</div><div><br></div><div>I now feel this is a bug in LLVM, do you agree? </div><div>Unfortunately, I do not know how to work around the current problem.</div><div><br></div><div>Thanks,</div><div>  Johan</div><div><br></div></div></div></div>