Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#71139 - [gcc] Enable default -fno-semantic-interposition
Attached to Project:
Arch Linux
Opened by Ray Song (MaskRay) - Sunday, 06 June 2021, 03:29 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:23 GMT
Opened by Ray Song (MaskRay) - Sunday, 06 June 2021, 03:29 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:23 GMT
|
DetailsGCC -fpic disables interprocedural optimizations (including inlining) for non-vague-linkage function definitions by default.
This is the biggest difference between -fpic/-fpie. -fno-semantic-interposition can bring back the lost performance. * cpython has defaulted to -fno-semantic-interposition. It was reported to have up to 30% speedup. https://bugs.python.org/issue38980 * The LLVM build system will default to -fno-semantic-interposition since 13.0.0. GCC built Clang will be 3% faster and 1~2% smaller (see https://reviews.llvm.org/D102453). * See https://maskray.me/blog/2021-05-09-fno-semantic-interposition for more technical details. Actually, Clang -fpic has always been allowing interprocedural optimizations. FreeBSD uses Clang, so it's well tested that most pieces of software work. I am going to create a GCC configure.ac patch (--enable-default-no-semantic-interposition) to enable default -fno-semantic-interposition. I think it will be a great addition to Arch Linux for any software which uses -fpic/-fPIC. |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:23 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/gcc/issues/3
Saturday, 25 November 2023, 20:23 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/gcc/issues/3
This is common misconception. Please read https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#interaction-with-ld_preload
I noticed that https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup is **severely flawed** and may be the source of many people's misconception.
I've emailed them to fix the information.
For a vague-linkage function definition, a call site in the same translation unit may inline the callee. Whether -fno-semantic-interposition is enabled/disabled does no affect the inline decision.
For a non-vague-linkage function definition, by default (-fsemantic-interposition) the -fpic mode does not allow a call site in the same translation unit to inline the callee or perform other interprocedural optimizations.
-fno-semantic-interposition re-enables interprocedural optimizations including inling.
If a caller inlines a callee, apparently using LD_PRELOAD to interpose the callee will not affect the caller.
But many other LD_PRELOAD usage still work.
For example, glibc interposition (malloc/fakeroot) works.
If the function you interpose is large, it's likely it will not be inlined into its callers anyway and LD_PRELOAD still works fine.
If a function is inlined, you can interpose both it and its call sites in the same TU.
You can add __attribute__((noinline)) to make it not inlinable so that interposition will definitely work.