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