On Tue, Jul 18, 2023 at 10:15:09PM +0900, JF Bastien wrote: > > > On Tue, Jul 18, 2023 at 8:41 PM serge via Phabricator <[1] > revi...@reviews.llvm.org> wrote: > > serge-sans-paille created this revision. > serge-sans-paille added reviewers: nickdesaulniers, jfb, aaron.ballman. > Herald added a subscriber: kristof.beyls. > Herald added a project: All. > serge-sans-paille requested review of this revision. > Herald added a project: clang. > Herald added a subscriber: cfe-commits. > > Empty class still use one byte, but there is no way to read that byte > programmatically in a legitimate way. Yet trivial auto var init always > generate a store for it and there is no programmatic way to prevent the > generation of that extra store. > > > > This is the same as padding, and is initialized on purpose. If it’s truly > unused then the optimizer will eliminate it… unless it can’t prove whether the > store is dead. > > Does this show up in any meaningless performance case? If so, can we optimize > it away?
It shows up in the top 10 hottest places in firefox where -ftrivial-auto-var-init injects code that cannot be removed. It cannot be removed because there's an opaque method call in the object that prevents the store from being removed, something along those lines: https://godbolt.org/z/o5asYGq8G For my particular case I can work around this, but as the behavior was different in GCC, I think it's at elast worth having this discussion :-) I understand your point wrt. padding and empty classes, harden by default. Can you think of any legitimate use of the actual value used to `anchor` the empty class? _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
