[Bug target/108184] New: rs6000: Use optimize_function_for_speed_p too early

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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