Received-SPF: pass (google.com: domain of linux-kernel+bounces-73686-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <CAHk-=wi8vZD7EXZfob-yhfDERyfzWxzMOzG9FsOuaKU-v6+PHA@mail.gmail.com>
 <538327ff-8d34-41d5-a9ae-1a334744f5ae@roeck-us.net> <CAHk-=wj6xj_cGmsQK7g=hSfRZZNo-njC+u_1v3dE8fPZtjCBOg@mail.gmail.com>
In-Reply-To: <CAHk-=wj6xj_cGmsQK7g=hSfRZZNo-njC+u_1v3dE8fPZtjCBOg@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 20 Feb 2024 12:37:13 -0800
Message-ID: <CAHk-=wg5+Sb3gWGxYumt4Sk9WsfXfqCN_B7uTXfY=jbF0fYBFQ@mail.gmail.com>
Subject: Re: Linux 6.8-rc5
To: Guenter Roeck <linux@roeck-us.net>, Matthew Auld <matthew.auld@intel.com>, 
	Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>, 
	=?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Tue, 20 Feb 2024 at 11:57, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> As far as I can tell, 'ps' is never modified, so the compiler should
> be able to just treat it as a constant.

. oh, and it looks like gcc *does* manage to do that on some targets.
Or at least some versions of gcc do. Because I don't see the build
failure on 32-bit x86 with gcc-13.2.1.

And apparently neither do you (you list csky, openrisc, parisc and xtensa).

I'm not sure why those particular four architectures - maybe it's
about the compiler version, maybe it's just about some basic quality
issues wrt 64-bit support on them - but yes, gcc does do a good job of
untangling that disgusting code in many cases.

The code was still unnecessarily overly complicated, and simply not
using 'u64' is definitely the right fix here. And while gcc did end up
avoding the 64-bit divide/modulus on x86, and did end up noticing that
n_pages was a constant '48', the code generation was still showing all
the signs of doing 64-bit arithmetic for no good reason).

We have good compilers, but that's not an excuse for writing bad code.

              Linus