[LLVMdev] C as used/implemented in practice: analysis of responses

[Sean Silva]

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>