llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Wed, 2018-02-07 at 15:47 -0800, Craig Topper wrote:
> I'll save you a review iteration. This is updated to match llvm
> coding style. Capital camel case variable names and uses
> LLVM_FALLTHROUGH instead of the comment.
Thanks. How's this for a test?

; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck
-check-prefix=X86 %s
; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck
-check-prefix=X64 %s

; If the target does not have 64-bit integer registers, emit 32-bit register
; names.

; X86: calll __x86_indirect_thunk_e{{[abcd]}}x
; X64: callq __x86_indirect_thunk_r

define void @q_modifier(i32* %p) {
entry:
  tail call void asm sideeffect "call __x86_indirect_thunk_${0:V}",
"r,~{dirflag},~{fpsr},~{flags}"(i32* %p)
  ret void
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/0f3de7de/attachment.bin>

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.

Also, huge thanks to David for jumping on several of the issues and the
help from folks building Linux to check them.

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).

-Chandler

On Wed, Feb 7, 2018 at 4:07 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> On Wed, 2018-02-07 at 15:47 -0800, Craig Topper wrote:
> > I'll save you a review iteration. This is updated to match llvm
> > coding style. Capital camel case variable names and uses
> > LLVM_FALLTHROUGH instead of the comment.
>
> Thanks. How's this for a test?
>
> ; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck
> -check-prefix=X86 %s
> ; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck
> -check-prefix=X64 %s
>
> ; If the target does not have 64-bit integer registers, emit 32-bit
> register
> ; names.
>
> ; X86: calll __x86_indirect_thunk_e{{[abcd]}}x
> ; X64: callq __x86_indirect_thunk_r
>
> define void @q_modifier(i32* %p) {
> entry:
>   tail call void asm sideeffect "call
__x86_indirect_thunk_${0:V}",
> "r,~{dirflag},~{fpsr},~{flags}"(i32* %p)
>   ret void
> }
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/ed1fd949/attachment.html>

On Thu, 2018-02-08 at 23:48 +0000, Chandler Carruth
wrote:
> 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.
For 64-bit it's fine. For 32-bit we *think* the retpoline bits are OK
but it doesn't build for other reasons on 32-bit. But that isn't new
breakage — 5.0 has the same problem with the latest kernel. I'll see if
we can work around that in the kernel, instead of relying on certain
inline asms getting optimised away before the compiler ever notices
that they're bogus.
> David, you had offered to work on the attribute: I'm actually happy
> to do that if you want to focus on testing things.
That sounds good to me; thanks.
>  One question I have: how important is this? Specifically, does the
> attribute need to get backported? 
No, we can live without it. It's a slight performance optimisation,
that none of the init code in the kernel itself actually has to be
built with retpolines. But it isn't imperative.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180208/b261459d/attachment.bin>