[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