Re: [GIT PULL] x86/build changes for v4.17

2018-06-07 Thread Greg KH
On Thu, Jun 07, 2018 at 12:23:31PM -0700, Nick Desaulniers wrote: > On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > > (re-sending as plain text) > > > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > > Th

Re: [GIT PULL] x86/build changes for v4.17

2018-06-07 Thread Nick Desaulniers
On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > (re-sending as plain text) > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > There are known-bugs with building a kernel with clang right now (I > > > pointed

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Linus Torvalds
On Thu, Apr 5, 2018 at 3:51 PM, James Y Knight wrote: > > Unfortunately, that behavior is required by the standard, it's not up to > compiler optimization to change. I actually mis-read your example - in your case it obviously does pass the array itself down to the call, and yes, it obviously nee

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread James Y Knight
On Thu, Apr 5, 2018 at 5:13 PM Linus Torvalds wrote: > And btw, I hate how stupid gcc is about "constant size arrays but acts > as a VLA because it wasn't an integer-constant-expression size" > things. > Your code generation example really is a sad sad example of it. A good > optimizer should hav

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Linus Torvalds
On Thu, Apr 5, 2018 at 1:51 PM, James Y Knight wrote: > > I had actually meant that the __builtin_constant_p **itself** had to be a > constant expression, not that its *argument* must be an I-C-E for > __builtin_constant_p to return true. I actually really wish that were true, and that it would a

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread James Y Knight
On Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the > > results of running optimization passes such as inlining for its > > definition/implementation of __bui

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Linus Torvalds
()() ha On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > GCC, however, mixes up the concept of a C "constant expression" with the > results of running optimization passes such as inlining for its > definition/implementation of __builtin_constant_p. Clang does not, and quite > likely wil

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread James Y Knight
I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen". GCC, however, mixes up the co

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Linus Torvalds
On Thu, Apr 5, 2018 at 12:24 AM, Peter Zijlstra wrote: > > I always assumed BT was a more expensive instruction than AND with > immediate. Oh, absolutely. That's why we do all those "depending on immediate or not". The reason I brought that case up is that "test_bit()" and "set_bit()" do this "i

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread James Y Knight
On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an object _field access_ can > > overflow. Clang does no

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Peter Zijlstra
On Thu, Apr 05, 2018 at 10:04:46AM +0200, Ingo Molnar wrote: >http://www.agner.org/optimize/instruction_tables.pdf > > The SkyLake costs for 'BT', 'AND' and 'TEST' variants are: > > BT m,i 2 2 > p06 p23 0.5

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > > for some reason the test_bit() case looks like > > this: > > > > #define test_bit(nr, addr) \ > > (__builtin_constant_p((nr)) \ > > ? constant_test_b

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Peter Zijlstra
On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > for some reason the test_bit() case looks like > this: > > #define test_bit(nr, addr) \ > (__builtin_constant_p((nr)) \ > ? constant_test_bit((nr), (addr)) \ > : vari

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Peter Zijlstra
On Wed, Apr 04, 2018 at 04:31:11PM -0700, Matthias Kaehlcke wrote: > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Then you're also missing a heap of optimizations in code like rb_erase_aug

Re: [GIT PULL] x86/build changes for v4.17

2018-04-05 Thread Peter Zijlstra
On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. Clang does not believe that can happen -- it assumes that an > object will s

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Kees Cook
On Wed, Apr 4, 2018 at 5:05 PM, Linus Torvalds wrote: > On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: >> >> From some experiments it looks like clang, in difference to gcc, does >> not treat constant values passed as parameters to inline function as >> constants. > > Yeah, I think gcc

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: > > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Yeah, I think gcc used to have those semantics a long time ago too. Many of our _

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Matthias Kaehlcke
El Wed, Apr 04, 2018 at 03:39:24PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > > > Getting our compiler team high to look into this might affect a timely > > (and correct ...) implementation of asm-goto and others important > > features. Arnd, do yo

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Nick Desaulniers
On Wed, Apr 4, 2018 at 10:13 AM Linus Torvalds < torva...@linux-foundation.org> wrote: > The fact that clang by default enables "-fmerge-all-constants" > behavior is just inexcusable. That's not just "let's do invalid > optimizations based on undefined behavior". That's an actual "let's do > known

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Nick Desaulniers
On Wed, Apr 4, 2018 at 12:17 PM Matthias Kaehlcke wrote: > Even with clang having known issues it would be preferable not to > break kernel builds with clang, if this doesn't place a signifcant > burden on the kernel. I'm not sure it is strictly necessary to 'wait' > for clang to enforce asm-goto

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > Getting our compiler team high to look into this might affect a timely > (and correct ...) implementation of asm-goto and others important > features. Arnd, do you have another, preferably simple instance to > keep our compiler folks (ha

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 3:21 PM, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. But that's not what the code does. It never _accessed_ the field. It only looked

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread James Y Knight
On Wed, Apr 4, 2018 at 3:42 PM Linus Torvalds wrote: > So we'd definitely want that "-fno-strict-overflow" to affect pointer > arithmetic too (or have a separate flag for the pointer equivalent of > "we play games that may temporarily wrap pointer values around".. The -fno-strict-overflow flag in

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Matthias Kaehlcke
El Wed, Apr 04, 2018 at 02:59:09PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > > > I understand this is annoying, but it seems I'm missing something: > > I think you're looking at !AEABI case. > > The AEABI case is worse. It ends up getting the co

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > I understand this is annoying, but it seems I'm missing something: I think you're looking at !AEABI case. The AEABI case is worse. It ends up getting the code from include/asm-generic/div64.h after defining a few helper inline asm func

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Matthias Kaehlcke
El Wed, Apr 04, 2018 at 11:11:36PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > >> > >> In most cases, this is used to implement a fast-path for a helper > >> function, so not doing it

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Arnd Bergmann
On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: >> >> In most cases, this is used to implement a fast-path for a helper >> function, so not doing it the same way as gcc just results in >> slower execution, but I assume we a

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Matthias Kaehlcke
El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > > > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > >> > >> > Yes, Chrome OS R67

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Arnd Bergmann
On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: >> >> > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built >> > with Clang for mult

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 12:26 PM, James Y Knight wrote: > > (OTOH, I _do_ expect clang to eventually gain support for a flag to treat > NULL-pointer deref as a legal operation instead of UB. I'm not really sure > it makes sense for the linux kernel, but it's a useful feature for the > compiler to p

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Josh Poimboeuf
On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL checks being deleted from the > >

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread James Y Knight
On Wed, Apr 4, 2018 at 12:59 PM Greg KH wrote: > Here is another horrible work around that was needed to get clang to > stop generating invalid code, beaec533fc27 ("llist: clang: introduce > member_address_is_nonnull()") That one caused a lot of odd failures by > users, I wonder what else is lurk

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Matthias Kaehlcke
El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > > > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > > with Clang for multiple x86 Chromebooks. > > But there are still _known_ miscompil

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Linus Torvalds
On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use "-fno-delete-null-pointer-checks" because we do *not*

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Greg KH
On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL checks being deleted from the > >

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Nick Desaulniers
(re-sending as plain text) On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > There are known-bugs with building a kernel with clang right now (I > pointed one out a few days ago about NULL checks being deleted from the > clang output for no good reason, which really is scary for obvious > reasons).

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Greg KH
On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked our

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Peter Zijlstra
On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > with Clang for multiple x86 Chromebooks. But there are still _known_ miscompilations > Given that it takes time for distributions to roll out new comp

Re: [GIT PULL] x86/build changes for v4.17

2018-04-04 Thread Peter Zijlstra
On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked our

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Nick Desaulniers
Speaking more with our internal LLVM teams, there ARE a few different approaches to implementing asm-goto in LLVM proposed, by external parties to Google. These proposals haven't progressed to code review, so we've asked our LLVM teams to reignite these discussions with increased priority, if not

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Matthias Kaehlcke
El Tue, Apr 03, 2018 at 11:51:18AM +0200 Ingo Molnar ha dit: > > * Peter Zijlstra wrote: > > > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > > > The biggest change is the forcing of asm-goto support on x86,

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Linus Torvalds
On Tue, Apr 3, 2018 at 1:59 AM, Peter Zijlstra wrote: > > It's not just spectre, I believe you yourself wanted to use asm-goto > somewhere in the x86 code: Absolutely. But I don't want to make it impossible for clang people to get their work done. Linus

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Peter Zijlstra
On Tue, Apr 03, 2018 at 11:51:18AM +0200, Ingo Molnar wrote: > If it's being relied on, or if there's actually something firmly planned, > which we could track, then I'd have no problem with reverting this change > and waiting one more kernel cycle or so. I don't see why the clang people can't go

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > > increases the GCC minimum supported version t

Re: [GIT PULL] x86/build changes for v4.17

2018-04-03 Thread Peter Zijlstra
On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86). > > So my biggest

Re: [GIT PULL] x86/build changes for v4.17

2018-04-02 Thread Matthias Kaehlcke
El Mon, Apr 02, 2018 at 03:38:21PM -0700 Matthias Kaehlcke ha dit: > El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > > i

Re: [GIT PULL] x86/build changes for v4.17

2018-04-02 Thread Matthias Kaehlcke
El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86). > > So my biggest

Re: [GIT PULL] x86/build changes for v4.17

2018-04-02 Thread Linus Torvalds
On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > The biggest change is the forcing of asm-goto support on x86, which > effectively > increases the GCC minimum supported version to gcc-4.5 (on x86). So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves to be forced, or can

[GIT PULL] x86/build changes for v4.17

2018-04-02 Thread Ingo Molnar
Linus, Please pull the latest x86-build-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus # HEAD: d6289f36aa7d5893d091a7a0c67eee7798719f03 x86/build: Don't pass in -D__KERNEL__ multiple times The biggest change is the forcing of asm-go