Hi Mike,
Thanks for the comments!
on 2023/1/18 04:57, Michael Meissner wrote:
> On Mon, Jan 16, 2023 at 05:39:04PM +0800, Kewen.Lin wrote:
>> Hi,
>>
>> Now we will check optimize_function_for_speed_p (cfun) for
>> TARGET_SAVE_TOC_INDIRECT if it's implicitly enabled. But
>> the effect of -msave-toc-indirect is actually to save the
>> TOC in the prologue for indirect calls rather than inline,
>> it's also good for optimize_function_for_size? So this
>> patch is to remove the check of optimize_function_for_speed
>> and make it work for both optimizing for size and speed.
>>
>> Bootstrapped and regtested on powerpc64-linux-gnu P8,
>> powerpc64le-linux-gnu P{9,10} and powerpc-ibm-aix.
>>
>> Any thoughts?
>>
>> Thanks in advance!
>
> Well in terms of size, it is only a savings if we have 2 or more indirect
> calls
> within a module, and we are not compiling for power10.
>
> On power9, if we have just one indirect call, then it is the same size.
>
> On power10, the -msave-toc-indirect switch does nothing, because we don't need
> TOCs when we have prefixed addressing.
Yes, exactly, so the test cases have the explicit option -mno-pcrel.
>
> So I have objection to the change. I suspect it may be better with a check
> for
> just optimize either for speed or size, and not for speed.
>
> The option however, can slow things down if there is an early exit to the
> function since the store would always be done, even if the function exits
> early.
>
Good point, I guessed that's why we only try to turn it on under the guard
flag_shrink_wrap_separate when there is no explicit -m{no-,}save-toc-indirect.
BR,
Kewen
