On Mon. 5 Feb. 2024 at 08:13, Finn Thain <fthain@xxxxxxxxxxxxxx> wrote:
On Sun, 4 Feb 2024, Vincent MAILHOL wrote:
(...)
Let's see if I understand. You are proposing that the kernel source carry an unquantified optimization, with inherent complexity and maintenance costs, just for the benefit of users who choose a compiler that doesn't work as well as the standard compiler. Is that it?
My proposal is quantified, c.f. my commit message: On an allyesconfig, with GCC 13.2.1, it saves roughly 8 KB. "Saving roughly 8kb" is a quantification. And clang use in the kernel is standardized: https://www.kernel.org/doc/html/latest/process/changes.html#current-minimal-requirements GCC may be predominant, but, although optional, clang v11+ is officially supported, and thus my patches should not neglect it. This is why I am asking whether or not clang support is important or not for m68k. If you tell me it is not, then fine, I will remove all the asm (by the way, the patch is already ready). But if there are even a few users who care about clang for m68k, then I do not think we should penalize them and I would not sign-off a change which negatively impacts some users. The linux-m68k mailing list should know better than me if people care about clang support. So let me reiterate the question from my previous message: is clang support important for you? I would like a formal acknowledgement from the linux-m68k mailing list before sending a patch that may negatively impact some users. Thank you.
At some point in the future when clang comes up to scrach with gcc and the builtin reaches parity with the asm, I wonder if you will then remove both your optimization and the asm, to eliminate the afore-mentioned complexity and maintenance costs. Is there an incentive for that work?
I will not follow up the evolution of clang support for m68k builtins. The goal of this series is to add a test to assert that all architectures correctly do the constant folding on the bit find operations (fifth patch of this series). It happens that m68k and hexagon architectures are failing that test, so I am fixing this as a one shot. After this series, I have no plan to do further work on m68k and hexagon architectures. Thank you for your understanding. Yours sincerely, Vincent Mailhol
