From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ubizjak@gmail.com>
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com
 [IPv6:2607:f8b0:4864:20::836])
 by sourceware.org (Postfix) with ESMTPS id 2851E39C3837
 for <gcc@gcc.gnu.org>; Thu,  5 Nov 2020 12:00:32 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2851E39C3837
Received: by mail-qt1-x836.google.com with SMTP id t5so857886qtp.2
 for <gcc@gcc.gnu.org>; Thu, 05 Nov 2020 04:00:32 -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=HXcU472sYXoa0T1gykySUz7B9TY5O207+3PdwLjdzpM=;
 b=fnrlvQpASpZ5UT7nsN7PYMGG/oakBv1ZELRJX4XVcZFMnIO2uDyHtlh43/4FYfVDMM
 Yv2aisrO9oOUWoDbGPhws0mhRniQggRCqiOztqL145/FCpd8Mgxv+250dSnW5tWZPW+8
 RwV90T/7lxp4C0yQxYTAbsc4FyiIrfgduao+KS4RCHQDg3AMQk+VOO8grm5tFNGpjwf4
 YdErDjhVMnAalN+LguCZLU6SrMjcWnfTJ16ZBYsWjdGkx53o3WkSofzXxWgpKX6kWiRh
 5bTYO6Q/jdrPHcQEGQWU7gPBXJY0DwlqfnBeRHwhkjenIoKbWhTZva+PWqMUTLVYyUrb
 gNww==
X-Gm-Message-State: AOAM533AnXssdIigh4Ygac/PDzDWK6Mi9eNVL0ZiozzAKLIIPuv/ae+9
 2K7tsLNevwuoWYPpsvRfV86e5PtZRDxSxVNX58E=
X-Google-Smtp-Source: ABdhPJyKF0fmPT296FDA2M/jGlJL13oKcVmGP6016tOLu3Nd87HP6fc4Yn056nz+Dp5+TDGlI166THWPRiosei0rXCc=
X-Received: by 2002:ac8:7b92:: with SMTP id p18mr1494173qtu.105.1604577631697; 
 Thu, 05 Nov 2020 04:00:31 -0800 (PST)
MIME-Version: 1.0
References: <CAFULd4aOca3k-AZ+ocMBqDRpH_kNisBQwfK0F4Jf7znsPxsrBw@mail.gmail.com>
 <CAFiYyc2a2ZY082MSjZiQNHo51ReYGAjyYB24hMhRQvbMY898vw@mail.gmail.com>
 <CAFULd4aoEG4b3AHKMcj-xK6OG0R-wH0HsjUoVyM6WnUB00gAtw@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051224220.9902@monopod.intra.ispras.ru>
 <CAFULd4aa1-+KP5A2Zfyjh8b+cnZoJmU8GKDb9auTuMOwt0L2oA@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051353350.9902@monopod.intra.ispras.ru>
In-Reply-To: <alpine.LNX.2.20.13.2011051353350.9902@monopod.intra.ispras.ru>
From: Uros Bizjak <ubizjak@gmail.com>
Date: Thu, 5 Nov 2020 13:00:20 +0100
Message-ID: <CAFULd4agQSZ=v5DQgF=vKZdn_fvAHyfmKawSVBPnvqtNWdgcvQ@mail.gmail.com>
Subject: Re: typeof and operands in named address spaces
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Jakub Jelinek <jakub@redhat.com>, X86 ML <x86@kernel.org>, 
 Andy Lutomirski <luto@amacapital.net>, GCC Development <gcc@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.3 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 <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 12:00:37 -0000

On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > What is the usecase for stripping the address space for asm operands?
> >
> > Please see the end of [2], where the offset to <mem> is passed in %rsi
> > to the call to this_cpu_cmpxchg16b_emu. this_cpu_cmpxchg16b_emu
> > implements access with PER_CPU_VAR((%rsi)), which expands to
> > %gs:(%rsi), so it is the same as %gs:<mem> in cmpxchg16b alternative.
> > The offset is loaded by lea <mem>, %rsi to %rsi reg.
>
> I see, thanks. But then with the typeof-stripping-address-space solution
> you'd be making a very evil cast (producing address of an object that
> does not actually exist in the generic address space). I can write such
> a solution, but it is clearly Undefined Behavior:
>
> #define strip_as(mem) (*(__typeof(0?(mem):(mem))*)(intptr_t)&(mem))
>
> void foo(__seg_fs int *x)
> {
>   asm("# %0" :: "m"(x[1]));
>   asm("# %0" :: "m"(strip_as(x[1])));
> }
>
> yields
>
> foo:
>         # %fs:4(%rdi)
>         # 4(%rdi)
>         ret
>
>
> I think a clean future solution is adding a operand modifier that would
> print the memory operand without the segment prefix.

I was also thinking of introducing of operand modifier, but Richi
advises the following:

--cut here--
typedef __UINTPTR_TYPE__ uintptr_t;

__seg_fs int x;

uintptr_t test (void)
{
 uintptr_t *p = (uintptr_t *)(uintptr_t) &x;
 uintptr_t addr;

 asm volatile ("lea %1, %0" : "=r"(addr) : "m"(*p));

 return addr;
}
--cut here--

Please note that the gcc documentation says:

--q--
6.17.4 x86 Named Address Spaces
-------------------------------

On the x86 target, variables may be declared as being relative to the
'%fs' or '%gs' segments.

'__seg_fs'
'__seg_gs'
    The object is accessed with the respective segment override prefix.

    The respective segment base must be set via some method specific to
    the operating system.  Rather than require an expensive system call
    to retrieve the segment base, these address spaces are not
    considered to be subspaces of the generic (flat) address space.
    This means that explicit casts are required to convert pointers
    between these address spaces and the generic address space.  In
    practice the application should cast to 'uintptr_t' and apply the
    segment base offset that it installed previously.

    The preprocessor symbols '__SEG_FS' and '__SEG_GS' are defined when
    these address spaces are supported.
--/q--

Uros.