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=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 9C271C3A5A1 for ; Thu, 22 Aug 2019 23:40:39 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 67A6221848 for ; Thu, 22 Aug 2019 23:40:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="oY+huU8Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67A6221848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i0wg9-0006vI-9K; Thu, 22 Aug 2019 23:39:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i0wg8-0006vA-4g for xen-devel@lists.xenproject.org; Thu, 22 Aug 2019 23:39:40 +0000 X-Inumbo-ID: 1b9fb530-c536-11e9-8980-bc764e2007e4 Received: from mail-vs1-xe41.google.com (unknown [2607:f8b0:4864:20::e41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1b9fb530-c536-11e9-8980-bc764e2007e4; Thu, 22 Aug 2019 23:39:39 +0000 (UTC) Received: by mail-vs1-xe41.google.com with SMTP id x20so4816163vsx.13 for ; Thu, 22 Aug 2019 16:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4uoNeBQLbN0a+q/BwRH3D7fLkKjuyXAdypRH/6RGSY=; b=oY+huU8ZOkkdSDOT+mRtkPQWywtVsTmfnQBMNe1L/eQujJo1j84+mnJlVRLNIKZrqo 1Tl9sc4rk+vuZ7duU4VFEJLFWM2EEq3Bjx76vsMkl+1/2KIzKUara/YqwPf/Epkgmlky gLCfNjgzwf9g9tPG6ut7PuJ8NVVUF4q2CYIkfo0LT5R/EICHDZ8haDBJmA0nvtfIeMiW k52e3pArknD/DA8d7Bqx0BTLsAVF3uBb7zzEILOZCD+ToY/ou3JvzVok7193pUyLvrYW /oWgKEVvm7qsiNfndvBbZSaDAy3SPL7lbMWZidNuyP7dnk0Y29IjG5bFEhQOeSgX3Jvv HWAA== 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=e4uoNeBQLbN0a+q/BwRH3D7fLkKjuyXAdypRH/6RGSY=; b=BI5PG9/0FSZ2VLY9Pu2Lsdj8WiiQCT6faPAiuYi5ENp/HF+ylkfQvcc68Cz1HfA76V mlyi5ToABvfxy5de/rzxfWBKjx9lojly3q79G8mZsgOly6wsWtU4kAORkxQ0AS1Mpg0H gY86MEvf/E0x/utw8UISbq0+WJ/sVuLhofby3EWHMEV+39Af4rBs8+VknTfSBJ/oW1US vm70WbtQVwhXK8cbCzYvLeeeRsfPzRyFSqzHPQlyiTafPt3bUusyggBgDJ2xJnpssBtF Hh5aKP0p4Ji9TE2+BBHRG3WYgnW038kbfH6Ky/zBv5prFlJhPfL+rzX5O2u/c3h/PMUK RLmQ== X-Gm-Message-State: APjAAAU0es0U3fWiKXDPYVG5AFQqe2ftMp/TWMyQrdY0/umCwUq0DgX+ 7R969Gh8w0Tl7loRFJmR8pXzchAx/Mc1UWggbqw= X-Google-Smtp-Source: APXvYqwT4JzkxWtwhWTcVs76Nw6HShKckP1SisLhRbjJLelHQHdJKc2en5rOeWoN6ID/EGShXzc6wbHlx3JDNyLtyFs= X-Received: by 2002:a67:fc14:: with SMTP id o20mr1148102vsq.160.1566517178982; Thu, 22 Aug 2019 16:39:38 -0700 (PDT) MIME-Version: 1.0 References: <20190812173019.11956-1-julien.grall@arm.com> <20190812173019.11956-21-julien.grall@arm.com> <937b6185-9a3e-f8b5-8335-2d948b3bb11a@arm.com> In-Reply-To: From: Julien Grall Date: Fri, 23 Aug 2019 00:39:26 +0100 Message-ID: To: Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Julien Grall , Volodymyr Babchuk Content-Type: multipart/mixed; boundary="===============8733770803370318593==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============8733770803370318593== Content-Type: multipart/alternative; boundary="000000000000fce6820590bd33e7" --000000000000fce6820590bd33e7 Content-Type: text/plain; charset="UTF-8" Sorry for the formatting. On Thu, 22 Aug 2019, 23:55 Stefano Stabellini, wrote: > On Thu, 22 Aug 2019, Julien Grall wrote: > > > > */ > > > > - dsb > > > > + lsr r1, r9, #FIRST_SHIFT > > > > + mov_w r0, LPAE_ENTRY_MASK > > > > > > ldr? > > > > What's wrong with the mov_w? Ok it is two instructions but... the > constant > > will be stored in a literal and therefore induce a memory load (see > patch #8). > > I am just wondering why you would choose mov_w when you can just do a > single simple ldr. > Well, I have just explained it and you likely saw the explanation in patch #8 as you acked it. So I am not sure what other explanation you are looking for. The choice between ldr rX, =... and mov_w is pretty much a matter of taste from our perspective. They will both take 64-bit in memory, the former because of one instruction and the constant stored in the literal pool. The latter because it is using two instructions. Technically, we could also reduce the number of instructions to one for mov_w depending on the constant size. But that's micro-optimization. mov_w will be slightly more efficient because you don't have an extra memory load (from loading from a pool). Although it is pretty much insignificant here. I also have to admit that the syntax for ldr is slightly confusing. I always have to look up in other place how it can be used and works. So I would like to keep the ldr use to the strict minimum, i.e. for non-cons value (such as symbol). Cheers, --000000000000fce6820590bd33e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the formatting.

On Thu, 22 Aug 2019, 23:55 St= efano Stabellini, <sstabellini= @kernel.org> wrote:
On Thu, = 22 Aug 2019, Julien Grall wrote:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 dsb
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 lsr=C2=A0 =C2=A0r1, r9, #FIRST_= SHIFT
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov_w r0, LPAE_ENTRY_MASK
> >
> > ldr?
>
> What's wrong with the mov_w? Ok it is two instructions but... the = constant
> will be stored in a literal and therefore induce a memory load (see pa= tch #8).

I am just wondering why you would choose mov_w when you can just do a
single simple ldr.

=
Well, I have just explained it and you likely saw the exp= lanation in patch #8 as you acked it. So I am not sure what other explanati= on you are looking for.

= The choice between ldr rX, =3D... and mov_w is pretty much a matter of tast= e from our perspective.

= They will both take 64-bit in memory, the former because of one instruction= and the constant stored in the literal pool. The latter because it is usin= g two instructions.

Tech= nically, we could also reduce the number of instructions to one for mov_w d= epending on the constant size. But that's micro-optimization.

mov_w will be slightly more effic= ient because you don't have an extra memory load (from loading from a p= ool). Although it is pretty much insignificant here.

I also have to admit that the syntax for ldr i= s slightly confusing. I always have to look up in other place how it can be= used and works.

So I wo= uld like to keep the ldr use to the strict minimum, i.e. for non-cons value= (such as symbol).

Cheer= s,
--000000000000fce6820590bd33e7-- --===============8733770803370318593== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============8733770803370318593==--