Uros Bizjak <ubiz...@gmail.com> writes: > On Thu, Jul 3, 2025 at 12:01 PM H.J. Lu <hjl.to...@gmail.com> wrote: >> >> When profiling is enabled with shrink wrapping, the mcount call may not >> be placed at the function entry after >> >> pushq %rbp >> movq %rsp,%rbp >> >> As the result, the profile data may be skewed which makes PGO less >> effective. >> >> Add --enable-x86-64-mfentry to enable -mfentry by default to use >> __fentry__, added to glibc in 2010 by: >> >> commit d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 >> Author: Andi Kleen <a...@linux.intel.com> >> Date: Sat Aug 7 21:24:05 2010 -0700 >> >> x86: Add support for frame pointer less mcount >> >> instead of mcount, which is placed before the prologue so that -pg can >> be used with -fshrink-wrap-separate enabled at -O1. This option is >> 64-bit only because __fentry__ doesn't support PIC in 32-bit mode. >> >> Also warn -pg without -mfentry with shrink wrapping enabled. The warning >> is disable for PIC in 32-bit mode. >> >> gcc/ >> >> PR target/120881 >> * config.in: Regenerated. >> * configure: Likewise. >> * configure.ac: Add --enable-x86-64-mfentry. >> * config/i386/i386-options.cc (ix86_option_override_internal): >> Enable __fentry__ in 64-bit mode if ENABLE_X86_64_MFENTRY is set >> to 1. Warn -pg without -mfentry with shrink wrapping enabled. >> * doc/install.texi: Document --enable-x86-64-mfentry. >> >> gcc/testsuite/ >> >> PR target/120881 >> * gcc.target/i386/pr120881-1a.c: New test. >> * gcc.target/i386/pr120881-1b.c: Likewise. >> * gcc.target/i386/pr120881-1c.c: Likewise. >> * gcc.target/i386/pr120881-1d.c: Likewise. >> * gcc.target/i386/pr120881-2a.c: Likewise. >> * gcc.target/i386/pr120881-2b.c: Likewise. >> * lib/target-supports.exp (check_effective_target_fentry): New. >> >> OK for master? > > OK in principle, but please allow some time for distro maintainers > (CC'd) to voice their opinion.
It looks good to me and I plan on us using it. I'd like opinions from one other group first before it goes in if possible though, as our perspective is different from others (e.g. we don't have to worry about old enterprise deployments). > > Thanks, > Uros. sam
