[feature] Consider compiling Perl with no-semantic-interposition when available

[atoomic]

As described in this article from RedHat about speeding up Python

RedHat starts compiling python using the -fno-semantic-interposition flag which is available since gcc 5.3.
Compiling with -fno-semantic-interposition leads to a 30% speedup for Python.

I wonder if such improvements would be true with Perl too.

Notice the reduction of assembly code instructions when using -fno-semantic-interposition.

There are a few drawbacks in using that flag, among them using LD_PRELOAD.

I do not think this would be an issue for Perl and XS code.

I'm trying to gather some feedbacks from the community.

• Any reasons we should not consider using -fno-semantic-interposition
• Did some of you already experimented compiling Perl with this flag?
• Should we consider promoting this flag as default when available?

I will experiment it soon and provide some benchmark metrics here later.

thanks for any input.

[eleksir]

This flag imply portability problems (not issues!) for vendored versions of perl5. That supposed to be distributed with some different products (i.e. Oracle Database). Those versions of perl can be built with older redhat/oracle linux but run on... even not on oracle/redhat linux, but for example, on arch or debian or something else. In these extreme situations LD_PRELOAD or LD_LIBRARY_PATH can be required.

Another wild situation: you need perl that is bundled by itself to run alongside with system perl, with its own module set.

Purpose of this flag (-fno-semantic-interposition) is for os distribution maintainers mostly, or you should build your program rather statically.

If you want this option that bad, you can put it in Configure flags, disabled by default with precaution of possible portability breakage in some corner/weird cases.

[Leont]

I suspect this is only going to matter in a shared libperl builds (because only then it will affect perl's own symbols), which only really makes sense for distributions anyway.

I would recommend measuring both static and shared libperl.

[bulk88]

Windows never had LD_PRELOAD or the PLT/GOT indirection concept of swapping out the pointer behind a ASCII symbol, where that ASCII C symbol's body is machine code or a process global var. Other than debugging/audit 3rd party addons that should never be used in production, there isn't any reason to hook other calls at run time, nor hook them statement by statement. Windows binaries, a reference to a symbol within the same binary is 1 CPU instruction with a current_Instruction_pointer_register+machine_code_const_offset operand. Linux requires 2 or 3 reads for each symbol, even within the same binary. Many years ago I propose modifying embed.fnc to create a Linux "visibility" file that is fed into GCC/Clang and then LTOed, so private perl interp symbols/funcs are removed by the linker if not part of any documented for XS/CPAN or dual life API (they really are dead code, but you can't prove dead/unused C functions on Linux because of LD_PRELOAD). But I never got around to it.

There are 2 or 3 concepts of removing LD_PRELOAD/close to pure static/disable DL.

Func B is defined in ELF A and has a call from Func A also defined in ELF A to Func B. Can ELF B which is dynloaded, hook/replace Func B inside ELF A, so all calls from any func inside (Func A example) ELF A to Func B inside ELF, goto an alternate definition of Func B in ELF B?

Can ELF B redirect calls from ELF C to Func B in ELF A to alternate Func B in ELF B but Func A in ELF A still calls Func B in ELF A since the hook is only inter-so/inter disk file.

Visibility helps with inlining/calling convention changing/PGO (nobody tried that with perl) the hottest branch into caller, cold branches stay in callee, prototype of callee is scrambled and not public anymore. https://stackoverflow.com/questions/51227608/how-exactly-is-fno-semantic-interposition-different-than-fvisibility-prot there are rumors no Unix CC ever implemented any optimizations for visibility tagging, but https://www.airs.com/blog/archives/307 is so old (2010) im not sure its quotable anymore. A SEGV when derefencing NULL violated ISO C anyways, the value of dereferencing address 0 is always 0, not a signal, so no modern CC implements C spec anyways.

[nwc10]

This seems to have stalled (which is a shame), as potential speedups are nice

Is this really a "feature" request? Does it really need the labels "need triage" and "Feature Request"? In the context of the RFC plan (as-is), this sort of change would be covered by the "regular" PR review process, and wouldn't need an RFC, so I don't think that it needs to be considered a feature (ie "mother, may I?" before even starting).

As in, please go for it! I'd love to know what benefits this might bring, and what the risks might be.

[richardleach]

Many years ago I propose modifying embed.fnc to create a Linux "visibility" file that is fed into GCC/Clang and then LTOed, so private perl interp symbols/funcs are removed by the linker if not part of any documented for XS/CPAN or dual life API (they really are dead code, but you can't prove dead/unused C functions on Linux because of LD_PRELOAD). But I never got around to it.

Is this covered by an existing issue? If not, could one be created? It could be something nice for a new core volunteer to work on.