https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Martin Jambor from comment #3) > (In reply to Richard Biener from comment #2) > > We have another bugreport that complains about SRA and Martin said he had > > patches but intended to wait for GCC 8. > > My patch for PR 78687 unfortunately won't help here, that one is aimed > at making the original aggregates disappear when in fact we want to > leave the intermediate aggregate in a chain of assignments intact, > quite the opposite of a normal mode of operation. > > > Note that I believe that store-merging, SRA (and bswap) are all passes that > > should be merged given they perform similar analyses and transforms. > > Yeah, and I am (slowly) starting to look in that direction. > > However, with the totally flow-insensitive SRA we have meanwhile, the > only remedy for this that I can think of is to throttle down total > scalarization here to never produce more than, say, > DECL_SIZE (candidate) / BITS_PER_WORD scalar replacements. > > What do you think? Yeah, but that's not sth for GCC 7 either. Note that we did get better both in FRE and DSE so we may no longer need SRA to perform some of the optimizations [in the early pipeline]. That said, the array cases we've seen are somewhat disturbing... maybe we can disable total scalarization for those?
