[LLVMdev] C as used/implemented in practice: analysis of responses
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>
> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev