On Fri, Sep 30, 2022 at 01:28:36AM +0200, Aaron Puchert wrote:
Am 29.09.22 um 09:22 schrieb Richard Biener:
Possibly. I'd say to truly identify worthwhile spots many users would need to do a lot of system-wide profiling (with all debuginfo installed!) and collecting the 1000 hottest pieces of code. Of course I bet that 90% will be in glibc and the kernel and the rest depends on what the user was doing during the profiling.
Debug info for the entire system is a lot. I wish we wouldn't strip .symtab, which is usually quite small and gets you half the way there.
My biggest CPU users are probably Firefox, codecs and compilers. The former two are doing dispatch quite frequently to my knowledge, the latter are probably unimpressed by new features. (Ok, maybe bextr as Clang uses lots of bit fields.)
It's way easier to just build everything with -v2 (or -v3) than to start bikeshedding on what _really_ matters.
As long as turning a bunch of hardware into scrap metal is on the table I'm afraid we're way out of bikeshedding territory. I think it should at least be discussed to which extent we might use newer hardware features without pulling the nuclear option.
Probably using something like -march=x86_64-v2 -mno-sse4.2 to reflect actual hardware feature availability. That could have been done by people defining these 'architecture levels' already but they picked arbitrary feature sets, did not provide any performance data, noted that many CPUs lack some fatures, and moved on with their plan to define 'architecture levels'. Thanks Michal