(original) (raw)
On Thu, Jul 2, 2015 at 9:07 AM, Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
On Wed, Jul 01, 2015 at 04:06:45PM +0100, Peter Sewell wrote:
\> - for some, OS developers are already routinely turning off
\> optimisations for the sake of more predictable semantics, e.g. with
\> fno-strict-aliasing.
This one is interesting, because the biggest problem with strict
aliasing is that there is no standard compliant way to override it.
The most basic issue is how the allocator is supposed to work
internally. If you can fully inline malloc/free pairs, it is practically
impossible to avoid aliasing conflicts.
I thought strict aliasing was more about types? I think memcpy is the standard escape hatch there. Generally speaking a fixed-size memcpy into a local variable is optimized down into the load/store that you want. This is e.g. how Support/Endian.h works. Yes, this is very awkward, and there might be some namespacing issues when writing memcpy itself though :)
-- Sean Silva
Other important use cases are things like vectorizing access, which
often means checking for the alignment of the data and casting to a more
appropiate type. Not everyone wants to implement strlen in assembler,
but writing a standard compliant and still fast implementation in C
seems impossible.
Joerg
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev