llvm dev - Feb 2018 - retpoline mitigation and 6.0

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>

On Thu, Feb 8, 2018 at 3:59 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> 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.
>
Cool, let us know if we can help here, but this at least tells us that
we're in pretty good shape to start backporting everything.

>
> > 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.
>
Makes sense, I'll do this as part of the requested cleanup to how we model
whether or not to do retpolines.

Thanks,
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/a2984646/attachment.html>

On Fri, 2018-02-09 at 00:09 +0000, Chandler Carruth
wrote:
> > 
> > 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.
>
> Cool, let us know if we can help here, but this at least tells us
> that we're in pretty good shape to start backporting everything.
Test case (build with -m32):


long long foo(void)
{
	long long ret;

	switch(sizeof(ret)) {
	case 1:
		asm ("movb $5, %0" : "=q" (ret));
		break;

	case 2:
		asm ("movw $5, %0" : "=r" (ret));
		break;

	case 4:
		asm ("movl $5, %0" : "=r" (ret));
		break;

	case 8: // this bit was complex, but OK.
		ret = 1;
	}
	return ret;
}

q.c:8:30: error: invalid output size for constraint '=q'
                asm ("movb $5, %0" : "=q" (ret));

Now looking up what the "q" constraint is, why it's being used for
the
1-byte version, and why compilation fails for those and not "r" which
blatantly can't take a 'long long' *either* but Clang seems to cope
with that one.

-------------- 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/20180209/860e866e/attachment.bin>