https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 13 Jan 2025, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 > > --- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> --- > gcc.target/powerpc/darn-3.c > > I'll quote the whole thing: > > === > static int darn32(void) { return __builtin_darn_32(); } > > int four(void) > { > int sum = 0; > int i; > for (i = 0; i < 4; i++) > sum += darn32(); > return sum; > } > === > > Okay, two insns, there's an add insn as well. But *not* unrolling this likely > makes bigger code already! This is because /* If there is call on a hot path through the loop, then there is most probably not much to optimize. */ else if (size.num_non_pure_calls_on_hot_path) { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Not unrolling loop %d: " "contains call and code would grow.\n", loop->num); return false; /* 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. */ else if (size.num_pure_calls_on_hot_path /* One IV increment, one test, one ivtmp store and one useful stmt. That is about minimal loop doing pure call. */ && (size.non_call_stmts_on_hot_path <= 3 + size.num_pure_calls_on_hot_path)) { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Not unrolling loop %d: " "contains just pure calls and code would grow.\n", loop->num); return false; } this _only_ gets pre-empted if the loop appears to shrink (from the removal of 1/3rd of stmts or other heuristics). Not estimating the calls to go away now makes the loop not shrinking and hit the call exception (otherwise we allow some growth). Not sure if DARN is properly marked pure (aka not writing to memory), probably not, since otherwise it would not have been considered having side-effects. So - fix your builtins! Not sure what the point about this testcase is - a sum of 4 random numbers should be replaceable with one random number & ~0x3. But sure, darn() probably cannot be pure (otherwise we'd CSE multiple calls). So - bad testcase. Do you have another one to show?
