[LLVMdev] C as used/implemented in practice: analysis of responses (original) (raw)

Sean Silva chisophugis at gmail.com
Thu Jul 2 14:19:22 PDT 2015

On Thu, Jul 2, 2015 at 9:07 AM, Joerg Sonnenberger <joerg at 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 at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/18287d96/attachment.html>

More information about the llvm-dev mailing list