https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #35 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 16 Apr 2024, rearnsha at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 > > --- Comment #34 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- > To be honest, I'm more concerned that we aren't eliminating a lot of these > copies during the gimple optimization phase. The memcpy is really a type > punning step (that's strictly ISO C compliant, rather than using the GCC union > extension), so ideally we'd recognize that and eliminate as many of the copies > as possible (perhaps using some form of view_convert or whatever gimple is > appropriate for changing the view without changing the contents). Yeah, there's currently no way to represent a change just in the effective type that wouldn't generate code in the end but still serves as barrier for these type related optimizations. When modifying the earlier store is an option then another possibility would be to attach multiple effective types to it in some way. Of course that's pessimizing as well. That said, the choice has been made to prune those "invalid" redundant store removals but as we see here the implemented checks are not working as intended.
