[llvm-dev] retpoline mitigation and 6.0

[Chandler Carruth via llvm-dev]

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>