From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A134BC388F9 for ; Thu, 12 Nov 2020 01:45:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D9492076E for ; Thu, 12 Nov 2020 01:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728115AbgKLBeE (ORCPT ); Wed, 11 Nov 2020 20:34:04 -0500 Received: from gate.crashing.org ([63.228.1.57]:46186 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728149AbgKLAt1 (ORCPT ); Wed, 11 Nov 2020 19:49:27 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 0AC0ew1I024417; Wed, 11 Nov 2020 18:40:58 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 0AC0evO1024412; Wed, 11 Nov 2020 18:40:57 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 11 Nov 2020 18:40:57 -0600 From: Segher Boessenkool To: Peter Zijlstra Cc: Nick Desaulniers , Uros Bizjak , GCC Development , X86 ML , Jakub Jelinek , Andy Lutomirski , linux-toolchains@vger.kernel.org, Christian Borntraeger , Will Deacon , Linus Torvalds , Michael Ellerman Subject: Re: typeof and operands in named address spaces Message-ID: <20201112004057.GN2672@gate.crashing.org> References: <20201109124713.GP2594@hirez.programming.kicks-ass.net> <20201109193851.GI2672@gate.crashing.org> <20201110075742.GT2594@hirez.programming.kicks-ass.net> <20201110201108.GQ2611@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201110201108.GQ2611@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Tue, Nov 10, 2020 at 09:11:08PM +0100, Peter Zijlstra wrote: > On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote: > > 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? > > Right, x86 Named Address Space: > > https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Named-Address-Spaces.html#Named-Address-Spaces > > Also, Google found me this: > > https://reviews.llvm.org/D64676 > > The basic problem seems to be they act exactly like qualifiers in that > typeof() preserves them, so if you have: GCC has the four standard type qualifiers (const, volatile, restrict, and _Atomic), but also the address space things yes. > > Maybe stripping all qualifiers is fine since you can add them back in > > if necessary? > > So far that seems sufficient. Although the Devil's advocate in me is > trying to construct a case where we need to preserve const but strip > volatile and that's then means we need to detect if the original has > const or not, because unconditionally adding it will be wrong. If you want to drop all qualifiers, you only need a way to convert something to an rvalue (which always has an unqualified type). So maybe make syntax for just *that*? __builtin_unqualified() perhaps? Which could be useful in more places than just doing an unqualified_typeof. Segher