[PATCH] D155580: [trivial-auto-var-init] Do not emit initialization code for empty class

[Serge Guelton via cfe-commits]

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]
> reviews at 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?