https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Peter Cordes from comment #2) > Are bug reports like this useful at all? It seems that a good fraction of > the missed-optimization bugs I file are things that gcc doesn't really have > the infrastructure to find. I'm hoping it's helping to improve gcc in the > long run, at least. I guess I could try to learn more about gcc internals > to find out why it misses them on my own before filing, but either way it > seems potentially useful to document efficient asm possibilities even if > gcc's current design makes it hard to take advantage. I think they are useful, even if some of them just are never resolved, some perhaps take a few years, thanks for the reports. For some of the reports we'll find out we have the infrastructure and can do it easily, for others it is possible to add infrastructure etc., but some will remain hard if we want to keep the compiler maintainable and supporting multiple architectures, in some cases fixing something requires very early detailed knowledge about architecture when we have at that point only approximate costs tuned from big amounts of code, etc. As for this exact ones, I'm now working on GIMPLE store merging improvements, but that of course won't handle this case. For RTL I had code to handle this at RTL DSE time, see PR22141 and https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01745.html The problem was that the patch caused performance regressions on PowerPC and it was hard to find a good cost model for it. Of course, for -Os the cost model would be quite simple, but although you count instructions, you were reporting this for -O3. Doing this at GIMPLE time is impossible, because it is extremely complex where exactly the variables are allocated, depends on many flags etc. (e.g. -fsanitize=address allocates pads in between them, some targets allocate them from top to bottom, others the other way around, ...), -fstack-protector* might protect some but not others and thus allocate in different buckets, alignment could play roles etc.
