https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 15 Jan 2025, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 > > --- Comment #22 from Jan Hubicka <hubicka at ucw dot cz> --- > > /* If there is pure/const call in the function, then we can > > still optimize the unrolled loop body if it contains some > > other interesting code than the calls and code storing or > > cumulating the return value. */ > > Note that these days we could optimize around non-pure/const functions > if modref summary is informative enough. Common case is when function > return value by writting to pointer passed as argument. > I am however not sure how to predict this - i.e. where to draw line > between useful and useless modref summary. note this case involves a (target) builtin, we could try to special-case some (the target could?), we have is_inexpensive_builtin which unconditionally says true for all target builtins ... But I think the motivating testcase we have is bad, so I'd like to see a better one. Also this doesn't feel like appropriate time to change such things - I'm not going to backport the side-effect change either.
