From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ubizjak@gmail.com>
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
 [IPv6:2607:f8b0:4864:20::834])
 by sourceware.org (Postfix) with ESMTPS id C4DF53851C1A
 for <gcc@gcc.gnu.org>; Thu,  5 Nov 2020 13:46:56 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C4DF53851C1A
Received: by mail-qt1-x834.google.com with SMTP id h12so1070586qtu.1
 for <gcc@gcc.gnu.org>; Thu, 05 Nov 2020 05:46:56 -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=Ke9NYvoeV5ql0k4UyJkMiNrxDW+5++FZMpFNurxVXIU=;
 b=c1CV9/l1abeSNu4VA/CnHLS4KhAqxQeB2HaU5lRwPOYbd0qWIZkhsWSJYJezvbG8Op
 qEfJsjwlepUsWCtuaAXoNnrnsef4wb/tWeZtUxdY36J1/kJSiyT1Z2YTg3aXsuWle2mJ
 XwjN9g061U1FoIAj+0sUtHi1QLFAHo/5fUcFPAJog3JmlpUdGm0+JY3QNJkMf8OaFC1t
 QFNglT55ONTZy6nSbunHhnaJ3350k5Iaf4GcFo+2b9eGyjGaZqXehNWQBVfX54m8u3SO
 UTGIsjl+Zh1J/Nrxj4eWLLPdI7BLnYaEIhjGXpjR6CA13kZYwB3/647QsTFs2/To0fW4
 G60Q==
X-Gm-Message-State: AOAM530t4kVPNYovL1u2TzJ5sPocOamMvTcoaiorJXCJx+Ehzk7O0D6E
 C8+KqazWxcZINXnqQOuUAhTqN0wbHDx8bfeAQkI=
X-Google-Smtp-Source: ABdhPJxHxLute8nDEe6fxR/Yv5luu1Iy/rutb+O7Myf1TkCrpnRgxdFtmNoTJ3H4H5KBUjfw0xZ2Ti/WBuQNfB7iofQ=
X-Received: by 2002:aed:3163:: with SMTP id 90mr2042729qtg.225.1604584016355; 
 Thu, 05 Nov 2020 05:46:56 -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>
 <CAFULd4agQSZ=v5DQgF=vKZdn_fvAHyfmKawSVBPnvqtNWdgcvQ@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051506090.9902@monopod.intra.ispras.ru>
 <CAFiYyc3HcJBwmN+EmVKW4_R0VVQM6dsBtHsGwjyfsKza5QNFcw@mail.gmail.com>
 <CAFULd4Zz+Ju+1RVUcJQzUsvZpJn1O52YLPfVZD2_b4i05VFSDA@mail.gmail.com>
 <CAFULd4ZHcfsK=H4OTqeYS+N+9y=sr=DuJ0TN4JYBCk5_G6gMRA@mail.gmail.com>
 <alpine.LNX.2.20.13.2011051612130.9902@monopod.intra.ispras.ru>
 <alpine.LNX.2.20.13.2011051631120.9902@monopod.intra.ispras.ru>
In-Reply-To: <alpine.LNX.2.20.13.2011051631120.9902@monopod.intra.ispras.ru>
From: Uros Bizjak <ubizjak@gmail.com>
Date: Thu, 5 Nov 2020 14:46:44 +0100
Message-ID: <CAFULd4bcCeNYQLj13k-VPteMUA1_BpdRCOnG8uB3JPF-i8Mo4A@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.5 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 13:46:57 -0000

On Thu, Nov 5, 2020 at 2:39 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>
> On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
>
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > No, this is not how LEA operates. It needs a memory input operand. The
> > > > above will report "operand type mismatch for 'lea'" error.
> > >
> > > The following will work:
> > >
> > >   asm volatile ("lea (%1), %0" : "=r"(addr) : "r"((uintptr_t)&x));
> >
> > This is the same as a plain move though, and the cast to uintptr_t doesn't
> > do anything, you can simply pass "r"(&x) to the same effect.
> >
> > The main advantage of passing a "fake" memory location for use with lea is
> > avoiding base+offset computation outside the asm. If you're okay with one
> > extra register tied up by the asm, just pass the address to the asm directly:
> >
> > void foo(__seg_fs int *x)
> > {
> >   asm("# %0 (%1)" :: "m"(x[1]), "r"(&x[1]));
> >   asm("# %0 (%1)" :: "m"(x[0]), "r"(&x[0]));
> > }
>
> Actually, in the original context the asm ties up %rsi no matter what (because
> the operand must be in %rsi to make the call), so the code would just
> pass "S"(&var) for the call alternative and "m"(var) for the native instruction.

Or pass both, "m"(var), and

uintptr_t *p = (uintptr_t *)(uintptr_t) &var;

"m"(*p)  alternatives, similar to what is done in the original patch.
The copy to %rsi can then be a part of the alternative assembly.

Uros.