https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108184
Bug ID: 108184
Summary: rs6000: Use optimize_function_for_speed_p too early
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
In the review of patch [1] for PR105818, Honza pointed out
"I think we should generally avoid doing decisions about size/speed
optimizations so early since the setting may change due to attributes or
profile feedback..."
I agreed that the current uses of optimize_function_for_speed_p in function
rs6000_option_override_internal are too early and can be inaccurate. I tried to
make the below test case to demonstrate it.
Compiled with -mdejagnu-tune=power8 -O3:
__attribute__ ((cold)) int
fusion_short (short *p)
{
return p[0x12345];
}
Since the function is attributed with cold, it's considered not to optimize for
speed, so we shouldn't break the sign extended loads and fuse it with the
addis, that is it's unexpected to see extsh generated but we have:
addis 3,3,0x2
lhz 3,18058(3)
extsh 3,3
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
