jrtc27 added a comment. In D79916#2279812 <https://reviews.llvm.org/D79916#2279812>, @Bdragon28 wrote:
> In D79916#2279045 <https://reviews.llvm.org/D79916#2279045>, @jrtc27 wrote: > >> This has significantly regressed FreeBSD's performance with the new version >> of Clang. It seems Clang does not inline functions at -O1, unlike GCC, and >> since FreeBSD currently compiles its kernel with -O whenever debug symbols >> are enabled[1] (which, of course, is almost always true), this results in >> all its `static inline` helper functions not being inlined at all, a pattern >> that is common in the kernel, used for things like `get_curthread` and the >> atomics implementations. >> >> [1] This is a dubious decision made in r140400 in 2005 to provide "truer >> debugger stack traces" (well, before then there was ping-ponging between -O >> and -O2 based on concerns around correctness vs performance, but amd64 is an >> exception that has always used -O2 since r127180 it seems). Given that GCC >> will inline at -O, at least these days, the motivation seems to no longer >> exist, and compiling a kernel at anything other than -O2 (or maybe -O3) >> seems like a silly thing to do, but nevertheless it's what is currently done. >> >> Cc: @dim @trasz > > This is actually SUCH a bad idea that a kernel built with -O will *not work > at all* on 32 bit powerpc platforms (presumably due to allocating stack > frames in the middle of assembly fragments in the memory management that are > supposed to be inlined at all times.) I had to hack kern.pre.mk to rquest -O2 > at all times just to get a functioning kernel. Well, -O0, -O1, -O2 and -O should all produce working kernels, and any cases where they don't are compiler bugs (or kernel bugs if they rely on UB) that should be fixed, not worked around by tweaking the compiler flags in a fragile way until you get the behaviour relied on. Correctness and performance are very different issues here. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79916/new/ https://reviews.llvm.org/D79916 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
