Thanks! On an unrelated note, since we're talking about assembly language, is there a reason that (from my experience) compilers are bad at optimizing certain mathematical operations down to their assembly instruction versions? For example, if I write this code:
Code:
sqrt(2.0+5.0+449201938193.500039218);
The fastest optimization I could imagine would be the compiler transforming that into:
Code:
MOV RAX, 0x120c667a1255a42
CVTSI2SD XMM0, RAX
SQRTSD XMM0, XMM0
(VSQRTSD would probably be faster, but it neeeds 3 operands, not two.)
Is there a reason compilers (to my knowledge and from what I've seen) don't optimize mathematical operations like this down to their instructions (e.g. SQRTSD for square root, ROUNDSD for rounding, etc.) when they encounter patterns of code that might indicate them, like a call to sqrt or round? Is it inaccuracies in the instructions themselves or something else? Or does this happen and I've just never had the right flags turned on or something? I usually compile my software with -mtune=native -march=native -O3 (sometimes -O2 though), but I'd think even at -O2 these kinds of patterns would be detectable. I know that instructions like FSIN aren't used because of possible inaccuracies but maybe that also applies to these?