Segher Boessenkool <seg...@kernel.crashing.org> writes:
> On Fri, Mar 31, 2023 at 03:06:41PM +0100, Richard Sandiford wrote:
>> This is an alternative presentation of the change that we discussed
>> a few weeks ago, and that you already tested:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613486.html
>>
>> The results seem to indicate that the patch had no effect on targets
>> other than aarch64. [A good thing, IMO. :-) The purpose of the
>> patch is to fix the aarch64 regression in a minimally invasive way.]
>
> If it is the same (I don't agree at all fwiw)
Why don't you agree that it's behaviourally the same? It's really just
a refactoring of my earlier patch.
> it has no effect on aarch64 either, other than on your single
> testcase. So that is a good reason to NAK this patch outside of stage
> 1 already.
But if it only affected this single testcase, I wouldn't see
improvements in 182 kernel objects :-)
>> I tried building an aarch64 linux kernel locally with -Os
>> -fno-schedule-insns{,2}.
>
> Completely unrealistic. No one builds anything they care for speed fo
> with -Os (and if people care for size, you still get better results
> with -O2 + some other tunings), and disabling scheduling is disastrous.
As discussed before, the point is to use these results to get an
idea of the scope of the change. And if we're using size to measure
the scope, it makes sense to align the compiler's goals with that,
since we then need to spend less time filtering the results for
oddities like different RA leading to different code layout, etc.
If we want to measure speed, we should do that. But I don't expect
a significant speed impact on the kernel either way (whether the
patch is good or bad).
Thanks,
Richard
