Re: [PATCH 09/11] x86: rework CONFIG_GENERIC_CPU compiler flags

[Arnd Bergmann]

On Thu, Dec 5, 2024, at 12:17, Andy Shevchenko wrote:
> On Thu, Dec 05, 2024 at 11:09:41AM +0100, Arnd Bergmann wrote:
>> On Thu, Dec 5, 2024, at 09:13, Andy Shevchenko wrote:
>> > On Wed, Dec 04, 2024 at 03:33:19PM -0800, Linus Torvalds wrote:
>> >> On Wed, 4 Dec 2024 at 11:44, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>
>> >> Will that work when you cross-compile? No. Do we care? Also no. It's
>> >> basically a simple "you want to optimize for your own local machine"
>> >> switch.
>> >
>> > Maybe it's okay for 64-bit machines, but for cross-compiling for 32-bit on
>> > 64-bit. I dunno what '-march=native -m32' (or equivalent) will give in such
>> > cases.
>> 
>> From the compiler's perspective this is nothing special, it just
>> builds a 32-bit binary that can use any instruction supported in
>> 32-bit mode of that 64-bit CPU,
>
> But does this affect building, e.g., for Quark on my Skylake desktop?

Not at the moment:

- the bug I'm fixing in the patch at hand is currently only present
  when building 64-bit kernels

- For a 64-bit target such as a Pineview Atom, it's only a problem
  if the toolchain default is -arch=native and you build with
  CONFIG_GENERIC_CPU

- If we add support for configuring -march=native and you build
  using that option on a Skylake host, that would be equally
  broken for 32-bit Quark or 64-bit Pineview targets that are
  lacking some of the instructions present in Skylake.

As I said earlier, I don't think we should offer the 'native'
option for 32-bit targets at all. For 64-bit, we either decide
it's a user error to enable -march=native, or change it to
-mtune=native to avoid the problem.

     Arnd