Don't launder the Optional's storage
Summary: `Optional` is often used for arguments and return values, and when the function is inlined it is important to be able to perform optimizations such as constant folding. `launder` forces a load on every access to the `Optional` in GCC, making it unsuitable for small hot functions. This is not specific to the `asm` trick we use to backport `launder` to pre-GCC7: the same code is generated in GCC7 with the builtin `std::launder`. `launder` is needed for correctness, as replacing an object that contains const or reference members in the same storage is UB. However, it seems to be a benign UB that real compilers don't take advantage of. In fact, the implementation of `std::optional` in both libstdc++ and libc++ does not launder the storage: https://github.com/gcc-mirror/gcc/blob/20d1a0756a0cf5072d0cdf3d2adab00063c224a7/libstdc%2B%2B-v3/include/std/optional#L881 https://github.com/llvm-mirror/libcxx/blob/8dd2afa20a01ee70e1a49c15de3de343aa8aa7d6/include/optional#L295 So it should be safe to follow these implementations and recover the perf hit. Reviewed By: luciang Differential Revision: D7689228 fbshipit-source-id: 8283de56b0934583773a0d19f315ae7a8d556e8c
Showing
Please register or sign in to comment