https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On January 9, 2021 4:17:17 AM GMT+01:00, "jiangning.liu at amperecomputing dot com" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598 > >--- Comment #5 from Jiangning Liu <jiangning.liu at amperecomputing dot >com> --- >> It has to be done with care of course, cost modeling is difficult >> (we need to have a good estimate of n and m or need to version >> the whole nest). That said, usually we attempt the reverse >transform. > >Before tuning the cost model good enough, we may implement this >optimization by >adding a new optimization command line option. This won't hurt gcc, >right? New options not enabled by default tend to bitrot, be broken from the start and won't be used by the lazy user. So I see no point in doing that. >> >> My personal opinion is that hinting the user to possibly refactor >> his code (guided by profiling to be not too noisy) is much >> prefered to the idea that the compiler can ever apply such transform >> to the loops where it matters and not to the loops where it is >> harmful. > >Sometimes, it is not always easy for the user to modify the code, and >even the >user may be lazy and reluctant to change the code. This kind of Memory >Gathering Optimization can make end-user's life easier.
