From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by sourceware.org (Postfix) with ESMTPS id 1E1B0385702F for ; Thu, 5 Nov 2020 08:56:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1E1B0385702F Received: by mail-qk1-x741.google.com with SMTP id l2so546523qkf.0 for ; Thu, 05 Nov 2020 00:56:21 -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:content-transfer-encoding; bh=cnYueiyHIsCGHsieItiyFmCTc59H5Scz8+snTEr7zPE=; b=nU2fTbaDbCQeSKz1YgJ/3lk1RzEaVR4KJ2LUxXdB+xX2x+WlULdEMTzLqomhhowjht 1i/jyK9Uw/Cp70o54rIY4AsQ7ZzeU3BKbGx5uQ89y3zfO4jkBQf1UGoTX8UQnvZGHur5 pp/lSqwbgx1EvuDFCQ6oZCSM39RnaiwERGsHLoz4wOXlr2tHzfaFg9EFq5wOBUtd6BI3 vtvHWvGfjiQ+0tCIA4uDOVcT3vmqnwgCAIm+f9ltjjPKU6Zi5t3jX2+xFy0jSejZeWzV X8ajBeYYKL2le8DEsrY8+BzeH1m1XBoEMOtz/k5Lw9twZR4En9xF2oAk2cRi4OuMo1Ex b1Bg== X-Gm-Message-State: AOAM5324atzz/C/tLGfLoyFS9uG54QKa8j5HyQdOW056nwvkOKWKoIkE JrLPCOG4kBtdar5kPci5FtXi5nYzXZ2DrBvV8s8= X-Google-Smtp-Source: ABdhPJzxa7geJfLNqaNsQqlOkEKrelLDIKHeqpGj8KsYDcfLswm0728xQnsvZZj0D985/3dpKwFN+nztU4aJemb0fc4= X-Received: by 2002:a37:9f0a:: with SMTP id i10mr1019513qke.61.1604566580635; Thu, 05 Nov 2020 00:56:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Uros Bizjak Date: Thu, 5 Nov 2020 09:56:09 +0100 Message-ID: Subject: Re: typeof and operands in named address spaces To: Richard Biener Cc: GCC Development , Jakub Jelinek , X86 ML , Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Thu, 05 Nov 2020 08:56:22 -0000 On Thu, Nov 5, 2020 at 8:26 AM Richard Biener wrote: > > On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrot= e: > > > > Hello! > > > > I was looking at the recent linux patch series [1] where segment > > qualifiers (named address spaces) were introduced to handle percpu > > variables. In the patch [2], the author mentions that: > > > > --q-- > > Unfortunately, gcc does not provide a way to remove segment > > qualifiers, which is needed to use typeof() to create local instances > > of the per-cpu variable. For this reason, do not use the segment > > qualifier for per-cpu variables, and do casting using the segment > > qualifier instead. > > --/q-- > > > > The core of the problem can be seen with the following testcase: > > > > --cut here-- > > #define foo(_var) \ > > ({ \ > > typeof(_var) tmp__; \ > > Looks like writing > > typeof((typeof(_var))0) tmp__; > > makes it work. Assumes there's a literal zero for the type of course. This is very limiting assumption, which already breaks for the following te= st: --cut here-- typedef struct { short a; short b; } pair_t; #define foo(_var) \ ({ \ typeof((typeof(_var))0) tmp__; \ asm ("mov %1, %0" : "=3Dr"(tmp__) : "m"(_var)); \ tmp__; \ }) __seg_fs pair_t x; pair_t test (void) { pair_t y; y =3D foo (x); return y; } --cut here-- So, what about introducing e.g. typeof_noas (not sure about the name) that would simply strip the address space from typeof? > Basically I try to get at a rvalue for the typeof. > > Is there a way to query the address space of an object so I can > put another variable in the same address space? I think that would go hand in hand with the above typeof_noas. Perhaps typeof_as, that would return the address space of the variable? > > asm ("mov %1, %0" : "=3Dr"(tmp__) : "m"(_var)); \ > > tmp__; \ > > }) > > > > __seg_fs int x; > > > > int test (void) > > { > > int y; > > > > y =3D foo (x); > > return y; > > } > > --cut here-- > > > > when compiled with -O2 for x86 target, the compiler reports: > > > > pcpu.c: In function =E2=80=98test=E2=80=99: > > pcpu.c:14:3: error: =E2=80=98__seg_fs=E2=80=99 specified for auto varia= ble =E2=80=98tmp__=E2=80=99 > > > > It looks to me that the compiler should remove address space > > information when typeof is used, otherwise, there is no way to use > > typeof as intended in the above example. > > > > A related problem is exposed when we want to cast address from the > > named address space to a generic address space (e.g. to use it with > > LEA): > > > > --cut here-- > > typedef __UINTPTR_TYPE__ uintptr_t; > > > > __seg_fs int x; > > > > uintptr_t test (void) > > { > > uintptr_t *p =3D (uintptr_t *) &y; > > uintptr_t *p =3D (uintptr_t *)(uintptr_t) &y; Indeed, this works as expected. > works around the warning. I think the wording you cite > suggests (uintptr_t) &y here, not sure if there's a reliable > way to get the lea with just a uintptr_t operand though. No, because we have to use the "m" constraint for the LEA. We get the following error: as1.c:10:49: error: memory input 1 is not directly addressable Uros.