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
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
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
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
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
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
()() 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
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
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
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
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
* 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
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
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
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
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
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 _
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
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
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
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*
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-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).
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
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
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
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
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,
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
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
* 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
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
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
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
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
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
49 matches
Mail list logo
