From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id A6624385780E for ; Tue, 10 Nov 2020 18:43:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A6624385780E Received: by mail-pg1-x535.google.com with SMTP id 62so10971622pgg.12 for ; Tue, 10 Nov 2020 10:43:10 -0800 (PST) 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=dz5c2tjYSezNPUIY6GDPjaSRV+1FfaFrJPAz5DPwOsY=; b=TmcAV3nMFNpePswpbRzQLo2oehXZWawGdhxfSX6uzWqfaXEesj5V0XrqZL6AzDmDzs NmHtgyc5SQKaAoDuAPUYLUjiaS7/nEi9FlWeLw5jvL+1V3MpDolTifdCoYzUXmaq+VUZ wHR3coW0iMoSLB2zCRGCE4imoACTQZz+VX6m0KYpgu4mC7oG+OKEa0ZcaCQO+PNkA2UO QQabsyoYGa50mBrHWYLV7+uWQRejekD8/aIB0mrq66vO+fHgW9tn/qgpjS/xgciJyUwk Ad4EsQ+4c5zeQEmBv6aCEeGrATObJAruxrMd11OQSOXsToMI2wvsoZUb+JRZNFr2GgWe OIpw== X-Gm-Message-State: AOAM5319w/PXR+KiU/lgX/IH+51hrNgfuxgIn0QW2QIf1q32umcVKjoH naHPp5/CmWQOP0MXx3j693R/9eiHmILyKyA0kz3Tpw== X-Google-Smtp-Source: ABdhPJzN1BxDz2TV9/A8bDhrE4sRtp+Soe7yTPwVbrNf05UVAQgDoVRgv3kOANPMLr+gxQqJvwJCJ+dvd3DXqcB20bU= X-Received: by 2002:a17:90a:4881:: with SMTP id b1mr532165pjh.32.1605033789499; Tue, 10 Nov 2020 10:43:09 -0800 (PST) MIME-Version: 1.0 References: <20201109124713.GP2594@hirez.programming.kicks-ass.net> <20201109193851.GI2672@gate.crashing.org> <20201110075742.GT2594@hirez.programming.kicks-ass.net> In-Reply-To: <20201110075742.GT2594@hirez.programming.kicks-ass.net> From: Nick Desaulniers Date: Tue, 10 Nov 2020 10:42:58 -0800 Message-ID: Subject: Re: typeof and operands in named address spaces To: Peter Zijlstra Cc: Segher Boessenkool , Uros Bizjak , GCC Development , X86 ML , Jakub Jelinek , Andy Lutomirski , linux-toolchains@vger.kernel.org, Christian Borntraeger , Will Deacon , Linus Torvalds , Michael Ellerman Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:43:12 -0000 On Mon, Nov 9, 2020 at 11:57 PM Peter Zijlstra wrote: > > Stripping const to delcare another variable is useful though. Sure C has > sharp edges, esp. if you cast stuff, but since when did that stop anyone > ;-) > > The point is, C++ has these very nice template helpers that can strip > qualifiers, I want that too, for much of the same reasons. We might not > have templates :-(, but we've become very creative with our > pre-processor. > > Surely our __unqual_scalar_typeof() cries for a better solution. Yeah, and those macros bloat the hell out of our compile times, for both compilers. I think it's reasonable to provide variants of typeof() that strip qualifiers. Some questions to flesh out more of a design. Would we want such a feature to strip all qualifiers or just specific individual ones? The more specific variants could be composed, ie. nonconst_typeof(x) y = x + 1; nonvol_typeof(z) w = z + 1; #define nonqual_typeof(v) nonconst_typeof(nonvol_typeof(v)) nonqual_typeof(v) k = v + 1; vs just: nonqual_typeof(v) k = v + 1; When I think of qualifiers, I think of const and volatile. I'm not sure why the first post I'm cc'ed on talks about "segment" qualifiers. Maybe it's in reference to a variable attribute that the kernel defines? Looking at Clang's Qualifier class, I see const, volatile, restrict (ah, right), some Objective-C stuff, and address space (TR18037 is referenced, I haven't looked up what that is) though maybe "segment" pseudo qualifiers the kernel defines expand to address space variable attributes? Maybe stripping all qualifiers is fine since you can add them back in if necessary? const volatile foo; const nonqual_typeof(foo) bar = foo; // strips off both qualifiers, re-adds const to bar -- Thanks, ~Nick Desaulniers