We've been building debug kernels (with 'makeoptions DEBUG=-g') with -O instead of -O2 ever since r140400. The original reason for that disappeared long ago, and plain -O on architectures other than amd64 leads to severe performance consequences, due to eg. disabling function inlining.
I'll try to experiment under QEMU. My guess is they will be fine, although I do most work on amd64 (which is built -O2 even for debug kernels) and MIPS, and on MIPS ddb whas often broken anyway.
-O was -O2 in GCC and Clang (and documented as such) for many years until the latest releases, so this is more keeping the status quo rather than regressing performance due to compiler defaults changing. Also amd64 already forces -O2 so (recently) got an "unfair" performance boost over other architectures (or more accurately didn't get a performance regression), yet most debugging time is likely spent on amd64 kernels due to its sheer popularity.
+1 from the PowerPC camp here.
Theoretically, -g and the ability of symbols should be enough to allow for debugging to work, even for stuff that has been inlined, as the fact that the inlining has happened is recorded in the debug data.
Possibly adding -fno-omit-frame-pointer may help an additional bit with debugging on platforms that don't normally use frame pointers, but that doesn't really have anything to do directly with inlining. (It's more about locals tracking, really)
This seems fine but please make sure you mention that llvm11 changed -O to -O1 whereas it was -O2 before so this is just keeping the previous opt level for llvm and only changes things if you compile with GCC.
Hmm, -O wouldn't hit this case for non-x86 (and non-powerpc) before I believe, but now does. If ports have been happy running at -O without -fno-strict-aliasing, i.e. using -O2 without it when using Clang 10 and below, do we still need this?