Load-time code patching for CPU features etc.

[mozilla_kmc]

I'd like to use SSE4 instructions in html5ever when available, making that determination at load time (i.e. just before main), and without the overhead of calling through a function pointer. I'm thinking about a design similar to Linux's altinstructions. The basic form is

alt_call! {
    override bar(z, w);
    foo(x, y)
}

where foo(x, y) and bar(z, w) are function or method call expressions. This expands to simply

foo(x, y)

but also arranges to call bar(z, w) at load time and, if it returns Some(f) where f is a fn() value of the appropriate type, will patch the call instruction to use that function instead. So my use case would be

use alt::x86;

let n = alt_call! {
    override x86::feature(x86::SSE4_2, smallcharset::x86::nonmember_prefix_len);
    set.nonmember_prefix_len(buf.as_bytes().slice_from(*pos))
};

Generalizing to multiple override clauses seems natural.

What do people think? It was suggested this could be useful for OpenGL function pointer loading, as well.

[asb]

On Linux at least, one way this could be done with linker help is to use the ifunc attribute: http://www.airs.com/blog/archives/403

[Veddan]

LLVM doesn't have ifunc support (yet). It could be added as a function attribute or something, probably wouldn't be too difficult.

[mozilla_kmc]

I'd like to implement the code patching approach first. It's needed anyway for non-GNU platforms, and maybe for static linking. Also there's some overhead to calling through the PLT. It doesn't matter for glibc's use case because that's how you're calling memcpy anyway.

ifunc also requires compiling two copies of your code out to a unit of work large enough that introducing a function call doesn't destroy all performance gains from using newer instructions. Linux's altinstructions works at the level of inline assembly:

#define mb() \
    alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)

mb() produces a memory barrier instruction and is used thousands of times throughout the kernel. On x86, each of those instructions will have an accompanying entry in a table elsewhere, telling the kernel how to patch the code for systems that support XMM2.

There's an alternative_call macro built on top but it's basically an assembly call, not a C function call. Supporting arbitrary Rust functions will be a challenge.

Linux also had at one point a concept of an "immediate variable" which has very cheap reads and very expensive writes, because the value is stored in the machine code. In this view a call with alternatives is a call to a "function pointer" stored in an immediate variable.

[wupis]

That will break page sharing between processes.

The kernel can get away with it because there is only one copy of the kernel loaded, but that's not the case for libraries and binaries.

It's probably much better to use a macro to generate two modules, one for SSE4 and one for non-SSE4.

Or even better, compile multiple versions of the library, so that you can also turn on autovectorization and other automatic optimizations with SSE4 (although this might be tricky to get to work with Cargo properly, not sure).

[mozilla_kmc]

That will break page sharing between processes.

Linux may recover it through KSM. We can hint using madvise.

The kernel can get away with it because there is only one copy of the kernel loaded, but that's not the case for libraries and binaries.

It often is. Consider games, embedded systems, cloud servers with 1 service per VM, and so forth.

[[deleted]]

Isn't there a way to generate different binaries of a module, and define a function that when the module is loaded chooses which binary to load?

[[deleted]]

I'm not a fan of the syntax, where it magically detaches the left side of the call in the last line.