Sujet : Re: Computer architects leaving Intel...
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.archDate : 09. Sep 2024, 10:06:43
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2024Sep9.110643@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : xrn 10.11
Terje Mathisen <
terje.mathisen@tmsw.no> writes:
float invsqrt(float x)
[...]
int32_t ix;
memcpy(&ix, &x, sizeof(ix));
>
and the compiler will see that x and ix can share the same register.
>
I don't suppose memmove() can be dependent upon to do the same?
There is nothing that prevents the compiler from doing it, or forcing
the compiler to to it with memcpy(). So a compiler could call the
function memcpy() for the code above, and optimize it as you prefer
with memmove(). What actual compilers do is something you can try
out. My experience is that memcpy() is given more love by compiler
maintainers than memmove(). It's as if, despite all the rethoric that
C programmers should "sanitize" programs to get rid of undefined
behaviours in our programs, they actually prefer that we use functions
with less defined behaviour like memcpy() instead of functions with
more defined behaviour like memmove().
- anton
-- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>