[llvm-dev] retpoline mitigation and 6.0

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 19 07:35:31 PST 2018

On Mon, Feb 19, 2018 at 4:31 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Mon, 2018-02-19 at 16:18 +0100, Hans Wennborg wrote:
>> Reid, is this what you fixed with r325049 that's also merged to 6.0?
> That's working for me, yes.
>> If so, do we have everything that's needed, or is there anything else
>> I should wait for?
> I wouldn't mind an opinion on
> https://bugs.llvm.org/show_bug.cgi?id=33587
> Clang for x86_32 will happily compile this:
>         long long ret;
>         asm ("movl $5, %0" : "=r" (ret)); // 32-bit reg for 64-bit val is fine.
> ... but not this:
>         long long ret;
>         asm ("movb $5, %0" : "=q" (ret)); // 8-bit reg for 64-bit val not fine.
> In practice, those cases go away in optimisation but the problem for us
> in building Linux is that the 8-bit case causes a build failure
> *before* the optimiser realises it'd never have to emit it anyway.

There are probably others better qualified to comment on the
functionality here, but from a 6.0 release point of view, this doesn't
sound like a regression. If a straight-forward fix emerges soon, maybe
we could merge it, but otherwise I'm not sure I can hold the release
for this.

> I can hack that up so that we're pretending to have 8-bit variables:
> https://lkml.org/lkml/2018/2/9/529
> But before I go further with that rather icky approach I'd like to know
> why it doesn't break for the "r" case, and if it's going to *keep*
> working. And if we can make the "q" case behave the same...

More information about the llvm-dev mailing list