meta-bug whiteboard MSVC turning on builtins memcpy memset memcmp strlen

[bulk88]

Description

This might eventually become a PR by me or someone else who has incentive to tackle this. But I need to archive the backstory and engineering details somewhere.

Research notes to myself about turning on memset/memcpy/memcmp CPU intrinsics feature inside WinPerl built with MSVC.

A naive person would say, are you stupid, it takes 20 seconds to add -Oi to /win32/GNUmakefile and this job/bug/task is done.

-Oi docs: https://learn.microsoft.com/en-us/cpp/build/reference/oi-generate-intrinsic-functions?view=msvc-170

I do not want to hit the -Oi button globally for many technical engineering reasons. If I do it, I know I am invasively altering the entire WinPerl+MSVC ecosystem forever with that button.

Also Perl in XS/C is not written in C89/C99 language. "Perl in XS/C" is written in Peroost Framework (jkjk) which is P5P's clone of https://www.boost.org/libraries/latest/grid/ . Peroost Framework's API Docs are located here -> https://perldoc.perl.org/perlclib .

P5P can modify Peroost, has modified, and alot of time and engineering went into creating Peroost's/XS's .h files. P5P and libperl.so.dll and ./Configure and metaconfig and miniperl.exe and the general toolchain can do many things, or automate, or improve, or correct, alot of things, defects, mousetraps, flaws, poor dev decisions in C lang, that you dont get with a stock CC toolchain.

I'm not going to go into details why Im not hitting the -Oi button right now.

Research notes:

A line of code somewhere in mro.xs.

AV* const isa_lin = newAV_alloc_xz(4);

expands to

#define newAV_alloc_xz(size) av_new_alloc(size,1)

expands to

PERL_STATIC_INLINE AV *
Perl_av_new_alloc(pTHX_ SSize_t size, bool zeroflag)
{
    AV * const av = newAV();
    SV** ary;
    PERL_ARGS_ASSERT_AV_NEW_ALLOC;
    assert(size > 0);

    Newx(ary, size, SV*); /* Newx performs the memwrap check */
    AvALLOC(av) = ary;
    AvARRAY(av) = ary;
    AvMAX(av) = size - 1;

    if (zeroflag)
        Zero(ary, size, SV*);

    return av;
}

Now lets analyze Zero(ary, size, SV*); in detail. After inlining it becomes

memset(array, 0, 0x20);

default MSVC WinPerl for the last 25 years emits

00000001800015EF 33 D2                                   xor     edx, edx        ; Val
00000001800015F5 44 8D 42 20                             lea     r8d, [rdx+20h]  ; Size
0000000180001608 48 8B C8                                mov     rcx, rax        ; Dst
000000018000160B FF 15 87 2A 00 00                       call    cs:__imp_memset

now I hack perl core headers with

#pragma intrinsic(memcpy)
#pragma intrinsic(memset)
#pragma intrinsic(memcmp)
#pragma intrinsic(strcat
#pragma intrinsic(strcmp)
#pragma intrinsic(strcpy)
#pragma intrinsic(strlen)

and recompile my xs module and I get

0000000180001926 0F 57 C0                                xorps   xmm0, xmm0
0000000180001945 0F 11 00                                movups  xmmword ptr [rax], xmm0
0000000180001948 0F 11 40 10                             movups  xmmword ptr [rax+10h], xmm0

lets count the bytes

before 2 + 4 + 3 + 6 = 15
after 3 + 3 + 4 = 10

Result: inlined memset() with basic SSE 1.0 ops wins the game.

It was a win performance wise, since it didn't do the formalities of a C call stack frame, and the large switch tree that lives inside libc function memset(), that creates an bounds checked aligned pointer, from an unaligned pointer, with something like

switch(ptr & 0xf) {
    case: 16
    case: 15
    case: 14
    case: 13
    case: 12
    //etc
}

didn't execute.

It was a win machine code bloat wise. 5 bytes shorter to do the same thing.

Steps to Reproduce

Disassembly a WinPerl compiled with MSVC, or with VS IDE, right click on ur src code -> left click "Go To Disassembly", press F11 a couple 100 times, or just press and hold F11 for a while with a podcast playing or a TV in the background.

Expected behavior

Code gen that is more like current LinPerl, or codegen that is more GCC or LLVM like than what MSVC produced currently for WinPerl.

Perl configuration

N/A

[tonycoz]

Did you examine non-constant-sized calls? gcc does:

        pxor    %xmm0, %xmm0
...
        movups  %xmm0, (%rax)
        movups  %xmm0, 16(%rax)

for your case, but for variable length memset()s it just calls the function.

[bulk88]

Did you examine non-constant-sized calls? gcc does:

        pxor    %xmm0, %xmm0
...
        movups  %xmm0, (%rax)
        movups  %xmm0, 16(%rax)

for your case, but for variable length memset()s it just calls the function.

The libc functions, infinity count of bytes, memcpy and strcpy strcmp and strlen memcpy were burned into single opcodes by Intel in 1979/1985 i386, its called the "REP" prefix.

But the opcodes are as politically controversial as Israel for CC authors and Asm devs ever since the opcodes were announced.

Intel has flip flopped multiple times in history, is the REP prefix implemented in the front end instruction decoder by spitting out an optimized for(){} loop, is it a dedicated HW single micro-op, or is it emulated like 8086 real mode is in 2025 with a SIGILL trap QEMU style in EFI/ACPI/APIC firmware.

https://stackoverflow.com/questions/27804852/assembly-rep-movs-mechanism

Figuring out what CCs at what versions with what -mtune cmd line args, and is it "worth it" for Perl in 2025 on post 2010 CPUs, is another research project I have to write up. If GCC devs unanimously decided REP prefix is ethnic cleansing again Foo Vendor Foo Micro architecture x64 CPUs, Perl has no way to use the opcode/intrinsic/built-in/inline, without GAS inline asm, or a GCC built-in intrinsic C function naming the Intel REP opcode with its Intel explicit asm name. This latter case means a new #define CopyIN(src, dst, n, type) macro in util.h. Final macro name is a community vote.

Examples

https://github.com/microsoft/mimalloc/blob/15220c684331d1c486550d7a6b1736e0a1773816/include/mimalloc-internal.h#L875
https://github.com/microsoft/mimalloc/blob/15220c684331d1c486550d7a6b1736e0a1773816/include/mimalloc-internal.h#L899

[bulk88]

https://github.com/golang/go/blob/master/src/runtime/memmove_amd64.s#L43 a random detailed comment I ran into, I dont have any comment good or bad on that file and its code

[bulk88]

https://github.com/mono/corert/blob/11136ad55767485063226be08cfbd32ed574ca43/src/Native/Runtime/GCMemoryHelpers.inl#L40

Posix Mono/MS .NET specifically uses a vectorized X-at-a-time DIYed unit of void * portable memcpy instead of "trusting" the CC. Postgres also has very similar code for zeroing and memcpying void * at a time that would be very useful in Perl since Newx blocks are always aligned to 8/16, unlike libc's 2 function symbols which are required to deal with unaligned U8* at all times (excluding any secret LTO/CC optimizations which aren't reliable, nor required for the CC to actually do to have compliant behavior).

Mono has never run on any CPU archs except i386/x64/ARM32/ARM64 and probably never will run on any others, but that C code looks like Clang or GCC are supposed to turn it (optimize it) into at bare minimum of 2 SSE move ops or 1 AVX move op. Even if it was accidentally compiled into basic ptr sized GPR move ops, it still is much more efficient that using U8* move ops in the loop.

[bulk88]

https://stackoverflow.com/questions/77572072/initializer-is-not-a-constant-only-with-certain-functions

I can not imagine any production use case for wanting to get the ISO C function pointer addresses of ISO C's memcpy/memset/memcmp/strlen function symbols and stick them in a static const C struct. This looks like a CS homework assignment from a college TA/professor. That OP's post history is all abstract CS questions with no process name, no C framework, no OS, no CC brand, no hobby purpose and no biz purpose.

Its okay for them to ask those questions, but my opinion is that sticking sticking memcpy in a struct field as a fnptr is unrealistic, no purpose, C code and not a back compat concern.

But that post does show something interesting about MSVC's internal design. Passing -Oi or doing

#pragma intrinsic( function_1 [, function_2 ... ] )

https://learn.microsoft.com/en-us/cpp/preprocessor/intrinsic

will turn the C standard lib linker symbols memcpy/memset/memcmp/strlen, into ISO C keywords!!! on MSVC.

I don't think anyone would ever notice or care except that college student needing to finish his homework. -Oi probably can be reversed case by case with

#pragma function( function1 [ , function2 ... ] )

https://learn.microsoft.com/en-us/cpp/preprocessor/function-c-cpp

The only production code use case I can think of, and it sounds far fetched, is some CPAN module that all 5 of these
-Win32-aware
-MSVC-aware
-currently compiling in 2025 on MSVC
-not SEGVing on Win64 NT kernel
-not SEGVing on Win32 NT kernel
-last updated on CPAN before March 22, 1993 DOB of Pentium CPU NO and NO & NO
-last update on CPAN after March 22, 1993 NO and NO
-last updated on CPAN between May 7, 1997 the DOB of P2 CPU, and no later than July 15, 1999? maybe, but far fetched

WinPerl's date of birth is Jan 27, 1997.

Revision: 0a753a764065
Date: 1/29/1997 1:11:00 AM
Message: [inseparable changes from patch from perl5.003_23 to perl5.003_24]

Subject: glob defaults to $_
Date: Mon, 27 Jan 1997 03:09:13 -0500
From: Gurusamy Sarathy
Files: op.c opcode.pl pod/perlfunc.pod t/op/glob.t

Subject: Win32 port
From: Gary Ng
Files: MANIFEST win32/*

A WinPerl C dev who wants to get the function pointers of MS UCRT or CRT's floor and ceil and fmod, must have some .h file included into their .xs, and that .h file is promising for WinPerlusers with486SXs, not 486DX`s or P1s, a super fast X87 FPU SW emulation library that is "faster than MS's implementation".

That .h could be creating a vtable of MSVC's native IEEE 754 ISO C FP helper functions, vs that .h's private and faster reimplementation of IEEE 754 ISO C helper functions.

I can't imagine any WinPerl C/XS module author, still caring or thinking in fall 1996 or at latest in summer 1997, about other WinPerl users still having an ancient n 1997 486SX PC.

I can't imagine that .h still being in any CPAN .tar.gz released in year 2001 or later. Its not a concern for P5P or me.

Another note about MSVC's internal design, doing -Oi or

#pragma intrinsic( function_1 [, function_2 ... ] )

on a basic ISO C Libc function that is a real linker function symbol that you can find with dl_sym/GetProcAddress.

#pragma intrinsic(memcpy) disables MSVC's __declspec(dllimport) optimization for the real Import table-ed memcpy function inside of perl54x.dll, when MSVC has to call the CRT's real memcpy function because size_t n argument is not a constexpr at C compile time (is unbounded).

So now I will see a 1 instruction big jmp __imp___memcpy@vcruntime.dll stub inside of perl54x.dll, and all of WinPerl's calls to memcpy inside of perl54x.dll go through that 1 instruction long jump stub, instead of using the __declspec(dllimport) machine code optimization on Win32/Win64 platforms.

I don't really see the loss of __declspec(dllimport) optimization for MSVC's/MS CRT's mem*()/str*() linker symbols as a concern. The benefits would far outweigh any too small to measurable perf decrease from that jump stub.

The jump stubs defect only applied to the family ofmem*()/str*() linker symbols when -Oi/#pragma intrinsic( is turned on.

Turning on -Oi/#pragma intrinsic( , will not remove __declspec(dllimport) optimization on all DLLs, and not all of the CRT's exported sybols.

Nothing would change regarding kernel32/gdi32/user32/ntdll.dll/etc. All 4 would still have the __declspec(dllimport) optimization active.

Its some kind of very tiny IR/RTL bytecode bug inside the MSVC binaries, that MS devs and nobody else really cares about.

I remember MSVC 2003 had this tiny bug, VC 2022 still has it. Oh well.

[bulk88]

https://metacpan.org/release/NERDVANA/Crypt-SecretBuffer-0.005/source/SecretBuffer.xs#L343

Someone assumed Perl's Zero token, aka, ISO C grammar token memset() can not be be rearranged, reordered, or ARM ISA's very out of order, very surprising, not x86 like, mem barrier fence behavior , cant happen on GCC/Clang CCs.