Re: Strict aliasing affects glibc 2.1.1 as well as Linux

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> Well, the thing is that it's a whole lot more flexible if you can do
> this from C sources.
> 
> Imagine trying out different algorithms, and having different tweaks for
> different circumstances. It would be a PAIN to have to recompile the
> compiler every time you came up with a faster version for a specific
> CPU.

There is nothing wrong with trying it out in assembler first. However,
adding it to the compiler later would make it accessible to all users
of the compiler, not just the kernel.

Also, you seem to be talking about inline assembly here. That's
perfectly fine as far as the aliasing dicussion goes. The concern is
the __constant_memcpy variant, which is done in plain (and incorrect
:) C code.

I believe Linux could do

#define memcpy(t, f, n) \
(__builtin_constant_p(n) ? \
 __builtin_memcpy((t),(f),(n)) : \
 __memcpy((t),(f),(n)))

today and not lose anything (at least on x86, didn't check all
architectures). IMHO, it is the compiler's job to know all about
efficient copying on a specific processor. Of course, the kernel
developer very often also knows these things, but I'm sure he'll use
this knowledge to complain when the compiler emits inefficient code
:-)

Regards,
Martin