Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))

Re:Std: Clamp generates less efficient assembly than std:min... by GrumpySloth on Tuesday January 16, 2024 @08:41AM (#39013148)

But then it uses AVX instructions. (You can replace -march=znver1 with just -mavx.)

When AVX isn’t enabled, the std::min + std::max example still uses fewer instructions. Looks like a random register allocation failure.

[ Parent | on HN ]

Re:Std: Clamp generates less efficient assembly than std:min... by gpderetta on Tuesday January 16, 2024 @08:48AM (#39013222)

The additional "movapd xmm0, xmm2" is mostly free as it is handled by renaming, but yes, it seems a quirk of the register allocator. It wouldn't be the first time I see GCC trying to move stuff around without obvious reasons.

[ Parent | on HN ]

Re:Std: Clamp generates less efficient assembly than std:min... by x1f604 on Thursday January 18, 2024 @04:13AM (#39039661)

I don't think it's a register allocation failure but is in fact necessitated by the ABI requirement (calling convention) for the first parameter to be in xmm0 and the return value to also be placed into xmm0.

So when you have an algorithm like clamp which requires v to be "preserved" throughout the computation you can't overwrite xmm0 with the first instruction, basically you need to "save" and "restore" it which means an extra instruction.

I'm not sure why this causes the extra assembly to be generated in the "realistic" code example though. See https://godbolt.org/z/hd44KjMMn

[ Parent | on HN ]