Received: by 10.213.65.68 with SMTP id h4csp2209613imn; Thu, 5 Apr 2018 10:49:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx49LVGfo1nRfp+iYHuJ3lIT1l2IQBxjljckvOPnHu4RhtBpsi1N45RLQv1rsaqEtBp5FqRf/ X-Received: by 10.99.101.194 with SMTP id z185mr5492768pgb.337.1522950560507; Thu, 05 Apr 2018 10:49:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522950560; cv=none; d=google.com; s=arc-20160816; b=wSUUbXrLNUZ5dmW7S8sAeQnP2xWZuM2OupN6vs7n2P7fljpq/unGRzZC+E6WQPRsuX bkyW4AwhqvFIAxKX48oC23OjRVacyXbchPFDNGZvS+0Q3q9HbsL1oYCRL2AnCko7RA1y vj5pB+0PmbVfHfcEkyCgvlAVo0HmHFTJOmzJriM+Zx7vzNpd8/4DYHt5ff87reWAdlwX xshSTxl0NjrF5UUWV67usaE1DvzGUKbi/p31qTjdPXrchlZuDveZsC6D/AdNe6lhrE20 8xnpR4hwjnE/OY/4hSvFdhDX+HtrPu/RCLlOaatlVXl4zXVD+LiGyTgGUVVBDNqxRJGd /5TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=AEsIpEyHuhGS3QX1B+hM+uvrVAaKxk+I/gTdmzqUsEc=; b=cVwjesOuuXFRk8ZDtwc6QdoerRf5UTfdlAkat88vOD8QSsVXBVJGzikjtnPWd7RyLn wAIZEbHQ/r46hn74+usaaXISt1Jxt5+pUXJ0tTjp0PsPhn3gnOWL9NSfj93TUS9fy6q6 7UKoVu7GIyXf5e3r7B1Qu7Ct+fHifmeilPzZfX1S9JdaYw9s3oaj22WVC901bLRdKCNk 8uvcL8fBo1H3RAZUYGENLT2nnZ3g/JrmzY0CzmI354AC+GrML6KLRcnaLq35L1BLt31s +KcD7O4NJe1mDfSLDs1RmhUo2EggeF0TN4Q0Ih0S7dyB06E7bDfYauVP5+GPRV93DjVR R9rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=l9GpiT07; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si5587136pgv.591.2018.04.05.10.49.06; Thu, 05 Apr 2018 10:49:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=l9GpiT07; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751532AbeDERrz (ORCPT + 99 others); Thu, 5 Apr 2018 13:47:55 -0400 Received: from mail-vk0-f68.google.com ([209.85.213.68]:45962 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751259AbeDERry (ORCPT ); Thu, 5 Apr 2018 13:47:54 -0400 Received: by mail-vk0-f68.google.com with SMTP id n64so11812967vkf.12 for ; Thu, 05 Apr 2018 10:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AEsIpEyHuhGS3QX1B+hM+uvrVAaKxk+I/gTdmzqUsEc=; b=l9GpiT07lNyTd+0DniKL30JfDZaAiXFVhyc6GpIaHn1Wd9JI1MO3ld1JGnHXvjGOAQ LyY0tKWiCp6Ipv6Lzgag0+sTs0ZKoEeNexkb5gjwLVtR6YbMEJP6TpAnf5QIkwlvrll1 qc2p03gLBihweZ/RdOrt+OiXU1TyB2neS+62qRma59zDvm9jduWDMjm1xv9Isp4MpJWk ZDR6zug44Z4ttpkzhZbqTYERCoyk5+Vt6kXzlkpr191kOd5T7THUDSUdXXG5MGvfU6R0 RV8fiDL2z1bA0FtsBSmpj9DjXd/91g+fJ3kSEX/P6Mip5UlgoSMR/I9x+WIaFae4S+vN ze/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AEsIpEyHuhGS3QX1B+hM+uvrVAaKxk+I/gTdmzqUsEc=; b=d2Cse9Jsrt9OAfiRWeCGkeRRBdIs0/AHpYhzm4UGVneava2MgYV6b7icqNhZC7CiRE uNTC3zfQ7gIXH0Fz0Xmz3RGHleOsXL0AExEOBwvOY5ABipbF2bi52fJr2x1d+Fjtua6b Yd/o0iuQBlycvypu7moztBK7FGKxV3/NgVdgRbicTY22gDjlmkwi4KgLHUH2S6iJVl4h P0EcDcFlPoJi29TIhDXLH2YTljfpqNnjJF8xqch/s2rMBfRmmAQRvqYPU/Lnvq6vfOu2 x8FH5KbBhZvzhUdfFg0V4ivM7KkOqDEvZf78FjSgdH3hr2ig9neXHUym5YrjyYF0elLw zB/w== X-Gm-Message-State: ALQs6tDfYlij1uccYtcDL+OpkbOiqVnzEWESH33kryvEqg51t6jYd8Aq H/lMHrrUxbVijPOWz0+Tec3l7kBODXOMKz0qwOkmKw== X-Received: by 10.31.58.5 with SMTP id h5mr14210118vka.167.1522950473360; Thu, 05 Apr 2018 10:47:53 -0700 (PDT) MIME-Version: 1.0 References: <20180404093007.GI4082@hirez.programming.kicks-ass.net> <20180404191724.GF87376@google.com> <20180404205848.GG87376@google.com> <20180404214639.GH87376@google.com> <20180404221744.GI87376@google.com> <20180404233111.GJ87376@google.com> <20180405072017.GN4043@hirez.programming.kicks-ass.net> In-Reply-To: <20180405072017.GN4043@hirez.programming.kicks-ass.net> From: James Y Knight Date: Thu, 05 Apr 2018 17:47:42 +0000 Message-ID: Subject: Re: [GIT PULL] x86/build changes for v4.17 To: Peter Zijlstra Cc: mka@chromium.org, Linus Torvalds , arnd@arndb.de, Ingo Molnar , Linux Kernel Mailing List , tglx@linutronix.de, Andrew Morton , Chandler Carruth , Stephen Hines , Nick Desaulniers , Kees Cook , groeck@chromium.org, Greg Hackmann , gregkh@linuxfoundation.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 will not ever, do that. That said, I do believe there are ongoing discussions as to how to best provide a useful alternative which is less semantically strange, and not too difficult for to conditionally adopt for a gcc/clang-compatible codebase such as the kernel. On Thu, Apr 5, 2018 at 3:20 AM Peter Zijlstra wrote: > 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_augmented() which is specifically constructed to take advantage > of constant propagation like that. > Other sites where we expect that to happen is __mutex_lock_common(), > __update_load_sum() and a bunch of others. There isn't strictly a bug > here, but not doing that constant propagation will still result in shit > code gen.