perf: move EG() and CG() in ZTS builds into __thread storage

[henderkes]

replay of #22231

Moves EG and CG into __thread storage after all. We first moved them into constant offsets (#22287) from *_tsrm_ls_cache, but I couldn't find a way to stop gcc or clang from reloading _tsrm_ls_cache base pointer between function calls, leading to an extra pointer load once per function.

This eliminates the pointer load, making the access sequence to EG/CG just a single mov (x64) / mrs + add + ldr (aarch64) under local-exec. initial-exec likewise loses the pointer load so 3 -> 2 instructions (x64).
cc @arnaud-lb

What I'm adding here to counter the global-dynamic fallback slowdown is the option to explicitly opt-in to initial-exec, under the knowledge that host programs loading it will need to increase the static tls surplus. This is not an issue for package providers.

PS: Actually figured out that the explicit model choice doesn't happen for musl, not sure about IE (static tls surplus on musl?), but LE should work just fine. That's for another PR though.

[arnaud-lb]

I like the --with-tsrm-tls-model idea.

Did a first pass, but I will take the time to review carefully.

[henderkes]

It's a bit of a pain to find these on mobile, so I'll pin just these two, but there's more.

It could eventually be reworked when all the symbols move directly into thread storage, but I've not even begun thinking about it. There's probably no point except for zend_ini_scanner_globals and what we still have in the front.

[henderkes]

The symbol is referenced as just a void* on windows

[henderkes]

Created the aarch64 global-dynamic first first, but I may as well look into teaching the JIT to take the address of _tsrm_ls_cache + offset instead of the mandatory load for a bit of JIT speedup.

[henderkes]

@arnaud-lb out of

zend_ini_scanner_globals))
virtual_cwd_globals))
zend_signal_globals_t))
zend_gc_globals_size())
php_core_globals))
sapi_globals_struct))
zend_accel_globals))
zend_jit_globals))

Which do you think would make sense moving too? gc globals probably and maybe virtual_cwd_globals?

[arnaud-lb]

alloc_globals is likely the most accessed global as every emalloc/efree and related fetch AG(mm_heap). I know that zend_alloc_globals is not exposed, but we could reserve enough space in _tsrm_ls_cache without exposing it:

struct _zend_tsrm_ls_cache {
	void *cache;
	void *self;
	zend_executor_globals eg;
	zend_compiler_globals cg;
	uint8_t ag[123];
	...
};

// zend_alloc.c:
ZEND_STATIC_ASSERT(sizeof(zend_tsrm_ls_cache.ag) >= sizeof(zend_alloc_globals));

#define AG(v) (((zend_alloc_globals*)&_tsrm_ls_cache.ag)->v)

[henderkes]

I think I already have a branch open for the AG move... perhaps it makes more sense moving it here, though.

Edit: my memory these days, it's already in. But I just realised we're keeping a useless write around.

[henderkes]

Created the aarch64 global-dynamic first first, but I may as well look into teaching the JIT to take the address of _tsrm_ls_cache + offset instead of the mandatory load for a bit of JIT speedup.

Proving too far outside my expertise. I think this is reviewable like this now, the JIT optimization could be done later in IR side to let us drop the self reference.

Unless @dstogov would like to have a go at it.

[arnaud-lb]

The changes look good in general, but it's a bit hard to follow. Possibly grouping abstractions in TSRM would help? Right now you need to have TSRM.*, zend.c, zend_globals_macros.h to understand what's going on.

The Windows changes make sense, but maybe @shivammathur can take a look as well?

[shivammathur]

TLS-backed EG skips worker persistent-list cleanup. Please preserve that cleanup.

[henderkes]

I'm not sure whether that will be possible to keep. Same problem as before when we moved AG and SCNG, we can't safely access another threads __thread variables.

[henderkes]

I don't see a way to reach it safely. Adding a detach marker gets us cleanup if the thread hasn't exited yet, but if it has, there's nothing we can do.

The only way to achieve this is moving persistent_list out of __thread storage, meaning out of EG. That's a large (albeit mechanical) change, though.

[henderkes]

@shivammathur I'm taking the reaction as the go-ahead for it. Going to bed now, but I should get to it on Sunday.