Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2070238ybk; Mon, 11 May 2020 11:11:39 -0700 (PDT) X-Google-Smtp-Source: APiQypKu4a8QcwokYenQCpA+mFz9iNRxrwWTzHT64f2gs/kuXzX5yKkd6PbuxOskpddoS9RMrZfH X-Received: by 2002:aa7:d5d5:: with SMTP id d21mr15048515eds.160.1589220699142; Mon, 11 May 2020 11:11:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589220699; cv=none; d=google.com; s=arc-20160816; b=DjN8DdEya2jSe23Qpv3mcx6UBlne4pY6fKsmTAvt8i1RMDwNV+96ZYxPMWWSZOahgJ BX2LNOiPBL/KAFyzGKsqg1oU+7G1QooMeIj+/0MNxFfW19Kiw0trCJg3JV/Y+/hdUjwZ UX2YNoDLiDcTQytBw+1Ikbd9Eoi1uCKLNcZfZcBJv/BpG/B5484QGqZsQ1KeAn0gp91e uAcSZdYKcz4AwWKyvgX/Mk6SoKUwmg+dALTracGumWsWgGKYMy0ohIM0JSjNQTYwp/8K BkkXrHjIHwai4RE4JInFpIm/hwIzKcIRy8Ii0i10vrErhuTMuHaT0sXMFMyFKBtKWdsb Hfiw== 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; bh=E2lGnntoMcDte3ggNmclJo3GyMi8lXxS2V6uxJFiNqM=; b=GyZhhkU/J/e3KF/qYxHhpeV1syLtiqBFpjHySz9TCQP+CS4LbCtMTLahVw/nGSGTD0 G9fRfk6T22N+h8bsiiVyGWzunUcyECDiWZs+kV8Gl5Xnm+z2TsPQefWP49amxM6l+R9J u60TY/fhnOfQYDBlmK0sPNPf29okOuYXyxh4eL2IyYQtFotppQrBdMcSzd4bG7b2JlWU XssLrW7mHnBUa6brqaaZfT5BhsxTzD0aBuhIvtYlMcdhnTOySSRsq7F2AQFl7Aotfb5T ccZckqprh66ieBQlEICgIsBAQZRXghRguDzdMzdjgyJI9NF9ZrTzxhVC6HPvxneDlH+3 pPng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Fb1AEy/a"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw24si6764807edb.248.2020.05.11.11.10.50; Mon, 11 May 2020 11:11:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Fb1AEy/a"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729785AbgEKSJO (ORCPT + 99 others); Mon, 11 May 2020 14:09:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726891AbgEKSJO (ORCPT ); Mon, 11 May 2020 14:09:14 -0400 Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD9A6C061A0C for ; Mon, 11 May 2020 11:09:13 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id j8so10813569iog.13 for ; Mon, 11 May 2020 11:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E2lGnntoMcDte3ggNmclJo3GyMi8lXxS2V6uxJFiNqM=; b=Fb1AEy/a1/hVWMniX/dCkcTEkF32oJosRltD5mrxheCwnduFPqmsl0w6y56EH1b8hI GcbfWL8LyZsC9ivjvAK5LWqCiWcBklyPM1VmxL+0TgK1iS26xC58kJT3v8vEeSgCSij+ I1XoVP6TKfWNUAwz619U9GGjRjfeThtSoC2+LbJkk3gHTdMOnZniY/XWYeEvkzewsAbX RBZ20Sg10RVcWAksY1ZIp6pH11CjP6OTriXbt9Fnc/LWl4xjVMtYCcV272nP+yAijtpS OKsfHn7+CWwJEYg4qEnbzubzqn9rYitiYJxs564K0SkWHTs8sQX5zEvlw6uYo8hhYdys nBBQ== 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=E2lGnntoMcDte3ggNmclJo3GyMi8lXxS2V6uxJFiNqM=; b=Rd/Gm3UFV0LNMYxWPWUs//63XM8ITZ8q1BFN3NcG9974rUHHSMBb+jybDW6TwesW8s siJpcm+lbT2fFuySPU6OM/RsXv/bCfGeAbUvPH3vb3BJ3Kv9fab+5cLfidKNJTPrupBy V+ZW5Yy8UyMg4JYNrpiY0RNKKml7oJ/YfprucmAg1czwLAJ1dB4WnrImRqOfpPusy6R8 Uu90/skzygxijkEP9jHKU1RD7dTK7eU9ARmXtwvvJ+icCziOLcaGMaaSYFMUxhxR0jvt xdbEBDkxCAm6dzHWFvwf8AiSZmKhF40jRLJzuW9vITrHErZOBE+vrnsHNRxAlfVtnS4n Bc7w== X-Gm-Message-State: AGi0PubeHgdkP1M6qKTWmLK6OAj5Xd81x1o7tUuVnPeLyc30hN7mqY5k AJdjT1wf2+obcBsJMQWdF8MPOW0vEqdzcIVLig== X-Received: by 2002:a6b:b512:: with SMTP id e18mr16445980iof.168.1589220552319; Mon, 11 May 2020 11:09:12 -0700 (PDT) MIME-Version: 1.0 References: <20200504230309.237398-1-ndesaulniers@google.com> In-Reply-To: From: Brian Gerst Date: Mon, 11 May 2020 14:09:01 -0400 Message-ID: Subject: Re: [PATCH] x86: support i386 with Clang To: Nick Desaulniers Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , David Woodhouse , Arnd Bergmann , Linus Torvalds , Dmitry Golovin , Dennis Zhou , Tejun Heo , Christoph Lameter , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Al Viro , Josh Poimboeuf , Masami Hiramatsu , Peter Zijlstra , LKML , clang-built-linux 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 On Mon, May 11, 2020 at 1:26 PM Nick Desaulniers wrote: > > Bumping for comment+review. > > On Mon, May 4, 2020 at 4:03 PM Nick Desaulniers wrote: > > > > GCC and Clang are architecturally different, which leads to subtle > > issues for code that's invalid but clearly dead. This can happen with > > code that emulates polymorphism with the preprocessor and sizeof. > > > > GCC will perform semantic analysis after early inlining and dead code > > elimination, so it will not warn on invalid code that's dead. Clang > > strictly performs optimizations after semantic analysis, so it will warn > > for dead code. > > > > Neither Clang nor GCC like this very much with -m32: > > > > long long ret; > > asm ("movb $5, %0" : "=q" (ret)); > > > > However, GCC can tolerate this variant: > > > > long long ret; > > switch (sizeof(ret)) { > > case 1: > > asm ("movb $5, %0" : "=q" (ret)); > > break; > > case 8:; > > } > > > > Clang, on the other hand, won't accept that because it validates the > > inline asm for the '1' case *before* the optimisation phase where it > > realises that it wouldn't have to emit it anyway. > > > > If LLVM (Clang's "back end") fails such as during instruction selection > > or register allocation, it cannot provide accurate diagnostics > > (warnings/errors) that contain line information, as the AST has been > > discarded from memory at that point. > > > > While there have been early discussions about having C/C++ specific > > language optimizations in Clang via the use of MLIR, which would enable > > such earlier optimizations, such work is not scoped and likely a > > multi-year endeavor. > > > > We also don't want to swap the use of "=q" with "=r". For 64b, it > > doesn't matter. For 32b, it's possible that a 32b register without a 8b > > lower alias (i.e. ESI, EDI, EBP) is selected which the assembler will > > then reject. > > > > With this, Clang can finally build an i386 defconfig. > > > > Reported-by: Arnd Bergmann > > Reported-by: David Woodhouse > > Reported-by: Dmitry Golovin > > Reported-by: Linus Torvalds > > Link: https://bugs.llvm.org/show_bug.cgi?id=33587 > > Link: https://github.com/ClangBuiltLinux/linux/issues/3 > > Link: https://github.com/ClangBuiltLinux/linux/issues/194 > > Link: https://github.com/ClangBuiltLinux/linux/issues/781 > > Link: https://lore.kernel.org/lkml/20180209161833.4605-1-dwmw2@infradead.org/ > > Link: https://lore.kernel.org/lkml/CAK8P3a1EBaWdbAEzirFDSgHVJMtWjuNt2HGG8z+vpXeNHwETFQ@mail.gmail.com/ > > Signed-off-by: Nick Desaulniers > > --- > > Note: this is a resend of: > > https://lore.kernel.org/lkml/20180209161833.4605-1-dwmw2@infradead.org/ > > rebased on today's Linux next, and with the additional change to > > uaccess.h. > > > > I'm happy to resend with authorship and reported by tags changed to > > suggested by's or whatever, just let me know. > > > > Part of the commit message is stolen from David, and part from Linus. > > Shall I resend with David's authorship and > > [Nick: reworded] > > ??? > > > > I don't really care, I just don't really want to carry this out of tree > > for our CI, which is green for i386 otherwise. > > > > > > arch/x86/include/asm/percpu.h | 12 ++++++++---- > > arch/x86/include/asm/uaccess.h | 4 +++- > > 2 files changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h > > index 2278797c769d..826d086f71c9 100644 > > --- a/arch/x86/include/asm/percpu.h > > +++ b/arch/x86/include/asm/percpu.h > > @@ -99,7 +99,7 @@ do { \ > > case 1: \ > > asm qual (op "b %1,"__percpu_arg(0) \ > > : "+m" (var) \ > > - : "qi" ((pto_T__)(val))); \ > > + : "qi" ((unsigned char)(unsigned long)(val))); \ > > break; \ > > case 2: \ > > asm qual (op "w %1,"__percpu_arg(0) \ > > @@ -144,7 +144,7 @@ do { \ > > else \ > > asm qual ("addb %1, "__percpu_arg(0) \ > > : "+m" (var) \ > > - : "qi" ((pao_T__)(val))); \ > > + : "qi" ((unsigned char)(unsigned long)(val))); \ > > break; \ > > case 2: \ > > if (pao_ID__ == 1) \ > > @@ -182,12 +182,14 @@ do { \ > > > > #define percpu_from_op(qual, op, var) \ > > ({ \ > > + unsigned char pfo_u8__; \ > > typeof(var) pfo_ret__; \ > > switch (sizeof(var)) { \ > > case 1: \ > > asm qual (op "b "__percpu_arg(1)",%0" \ > > - : "=q" (pfo_ret__) \ > > + : "=q" (pfo_u8__) \ > > : "m" (var)); \ > > + pfo_ret__ = (typeof(var))(unsigned long)pfo_u8__; \ > > break; \ > > case 2: \ > > asm qual (op "w "__percpu_arg(1)",%0" \ > > @@ -211,12 +213,14 @@ do { \ > > > > #define percpu_stable_op(op, var) \ > > ({ \ > > + unsigned char pfo_u8__; \ > > typeof(var) pfo_ret__; \ > > switch (sizeof(var)) { \ > > case 1: \ > > asm(op "b "__percpu_arg(P1)",%0" \ > > - : "=q" (pfo_ret__) \ > > + : "=q" (pfo_u8__) \ > > : "p" (&(var))); \ > > + pfo_ret__ = (typeof(var))(unsigned long)pfo_u8__; \ > > break; \ > > case 2: \ > > asm(op "w "__percpu_arg(P1)",%0" \ > > diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h > > index d8f283b9a569..cf8483cd80e1 100644 > > --- a/arch/x86/include/asm/uaccess.h > > +++ b/arch/x86/include/asm/uaccess.h > > @@ -314,11 +314,13 @@ do { \ > > > > #define __get_user_size(x, ptr, size, retval) \ > > do { \ > > + unsigned char x_u8__; \ > > retval = 0; \ > > __chk_user_ptr(ptr); \ > > switch (size) { \ > > case 1: \ > > - __get_user_asm(x, ptr, retval, "b", "=q"); \ > > + __get_user_asm(x_u8__, ptr, retval, "b", "=q"); \ > > + (x) = x_u8__; \ > > break; \ > > case 2: \ > > __get_user_asm(x, ptr, retval, "w", "=r"); \ > > -- > > 2.26.2.526.g744177e7f7-goog > > > > > -- > Thanks, > ~Nick Desaulniers This looks like the same issue that we just discussed for bitops.h. Add the "b" operand size modifier to force it to use the 8-bit register names (and probably also needs the "w" modifier in the 16-bit case). -- Brian Gerst