<div dir="ltr">Bringing everything back to this thread -- we now have %V support landed in top-of-tree, so wanted to get confirmation that top-of-tree is healthy for the kernel, or see what else we need to do.<div><br></div><div>Also, huge thanks to David for jumping on several of the issues and the help from folks building Linux to check them.</div><div><br></div><div>David, you had offered to work on the attribute: I'm actually happy to do that if you want to focus on testing things. One question I have: how important is this? Specifically, does the attribute need to get backported? There are two approaches there, one of which matches a code review request anyways, but would be more disruptive to backport all the way to 5.0, so I'd like to get a sense of which approach to take (a somewhat hacky one that will definitely backport or the cleaner solution).</div><div><br></div><div>-Chandler</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 7, 2018 at 4:07 PM David Woodhouse <<a href="mailto:dwmw2@infradead.org">dwmw2@infradead.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2018-02-07 at 15:47 -0800, Craig Topper wrote:<br>
> I'll save you a review iteration. This is updated to match llvm<br>
> coding style. Capital camel case variable names and uses<br>
> LLVM_FALLTHROUGH instead of the comment.<br>
<br>
Thanks. How's this for a test?<br>
<br>
; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck -check-prefix=X86 %s<br>
; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck -check-prefix=X64 %s<br>
<br>
; If the target does not have 64-bit integer registers, emit 32-bit register<br>
; names.<br>
<br>
; X86: calll __x86_indirect_thunk_e{{[abcd]}}x<br>
; X64: callq __x86_indirect_thunk_r<br>
<br>
define void @q_modifier(i32* %p) {<br>
entry:<br>
  tail call void asm sideeffect "call __x86_indirect_thunk_${0:V}", "r,~{dirflag},~{fpsr},~{flags}"(i32* %p)<br>
  ret void<br>
}</blockquote></div>