diff options
author | Rich Felker <dalias@aerifal.cx> | 2022-09-30 21:20:32 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2022-10-19 14:01:31 -0400 |
commit | 833a469167521040c7ae94f3c990e258e29445f9 (patch) | |
tree | fa7510dabaa9c099afe7a4ca51c798f2a39a5dfc /src/ldso/m68k/dlsym.s | |
parent | e6e8213244a816511e95e14fb99176442922abac (diff) | |
download | musl-833a469167521040c7ae94f3c990e258e29445f9.tar.gz musl-833a469167521040c7ae94f3c990e258e29445f9.tar.bz2 musl-833a469167521040c7ae94f3c990e258e29445f9.tar.xz musl-833a469167521040c7ae94f3c990e258e29445f9.zip |
configure: disable TBAA optimization because most compilers are buggy
unlike most projects that use -fno-strict-aliasing, we aim to have all
sources respect the C language rules for effective type that make
type-based alias analysis optimizations possible. unfortunately, it
turns out that there are deep, and likely very difficult to fix, flaws
in the TBAA performed by GCC and likely other compilers, whereby this
kind of optimization can transform code that follows the rules
strictly in ways that will make it malfunction. see for example GCC
bugs 107107 and 107115, the latter of which also affects clang.
there are not presently any known instances of breakage due to wrong
type-based aliasing optimizations in our codebase. nonetheless, since
the transformations are unsound and could introduce breakage,
configure CFLAGS to build with -fno-strict-aliasing.
some casual analysis of the effects on codegen suggest that this is
unlikely to affect performance except possibly in the regex engine. in
general, we should probably prefer making better use of the restrict
keyword over relying on types to imply non-aliasing for optimization
purposes; doing so should be able to get back any performance that was
lost and more, should it turn out to matter (unlikely).
Diffstat (limited to 'src/ldso/m68k/dlsym.s')
0 files changed, 0 insertions, 0 deletions