public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kewen.Lin" <linkw@linux.ibm.com>
To: Jan Hubicka <hubicka@kam.mff.cuni.cz>
Cc: Richard Sandiford <richard.sandiford@arm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Jan Hubicka <hubicka@ucw.cz>,
	Richard Biener <richard.guenther@gmail.com>
Subject: Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]
Date: Mon, 29 Aug 2022 14:35:07 +0800	[thread overview]
Message-ID: <5404908f-76d9-8898-3621-1f54064892fb@linux.ibm.com> (raw)
In-Reply-To: <0122f231-450a-1280-ba23-fb7127412aa9@linux.ibm.com>

on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
> on 2022/7/11 11:42, Kewen.Lin wrote:
>> on 2022/6/15 14:20, Kewen.Lin wrote:
>>> Hi Honza,
>>>
>>> Thanks for the comments!  Some replies are inlined below.
>>>
>>> on 2022/6/14 19:37, Jan Hubicka wrote:
>>>>> Hi,
>>>>>
>>>>> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
>>>>> if func->decl is not null but no cgraph node is available for it.
>>>>> As PR105818 shows, this could give unexpected result.  For the
>>>>> case in PR105818, when parsing bar decl in function foo, the cfun
>>>>> is a function structure for foo, for which there is none cgraph
>>>>> node, so it returns OPTIMIZE_SIZE_NO.  But it's incorrect since
>>>>> the context is to optimize for size, the flag optimize_size is
>>>>> true.
>>>>>
>>>>> The patch is to make optimize_function_for_size_p to check
>>>>> optimize_size as what it does when func->decl is unavailable.
>>>>>
>>>>> One regression failure got exposed on aarch64-linux-gnu:
>>>>>
>>>>> PASS->FAIL: gcc.dg/guality/pr54693-2.c   -Os \
>>>>> 	    -DPREVENT_OPTIMIZATION  line 21 x == 10 - i
>>>>>
>>>>> The difference comes from the macro LOGICAL_OP_NON_SHORT_CIRCUIT
>>>>> used in function fold_range_test during c parsing, it uses
>>>>> optimize_function_for_speed_p which is equal to the invertion
>>>>> of optimize_function_for_size_p.  At that time cfun->decl is valid
>>>>> but no cgraph node for it, w/o this patch function
>>>>> optimize_function_for_speed_p returns true eventually, while it
>>>>> returns false with this patch.  Since the command line option -Os
>>>>> is specified, there is no reason to interpret it as "for speed".
>>>>> I think this failure is expected and adjust the test case
>>>>> accordingly.
>>>>>
>>>>> Is it ok for trunk?
>>>>>
>>>>> BR,
>>>>> Kewen
>>>>> -----
>>>>>
>>>>> 	PR target/105818
>>>>>
>>>>> gcc/ChangeLog:
>>>>>
>>>>> 	* predict.cc (optimize_function_for_size_p): Check optimize_size when
>>>>> 	func->decl is valid but its cgraph node is unavailable.
>>>>>
>>>>> gcc/testsuite/ChangeLog:
>>>>>
>>>>> 	* gcc.target/powerpc/pr105818.c: New test.
>>>>> 	* gcc.dg/guality/pr54693-2.c: Adjust for aarch64.
>>>>> ---
>>>>>  gcc/predict.cc                              | 2 +-
>>>>>  gcc/testsuite/gcc.dg/guality/pr54693-2.c    | 2 +-
>>>>>  gcc/testsuite/gcc.target/powerpc/pr105818.c | 9 +++++++++
>>>>>  3 files changed, 11 insertions(+), 2 deletions(-)
>>>>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105818.c
>>>>>
>>>>> diff --git a/gcc/predict.cc b/gcc/predict.cc
>>>>> index 5734e4c8516..6c60a973236 100644
>>>>> --- a/gcc/predict.cc
>>>>> +++ b/gcc/predict.cc
>>>>> @@ -268,7 +268,7 @@ optimize_function_for_size_p (struct function *fun)
>>>>>    cgraph_node *n = cgraph_node::get (fun->decl);
>>>>>    if (n)
>>>>>      return n->optimize_for_size_p ();
>>>>> -  return OPTIMIZE_SIZE_NO;
>>>>> +  return optimize_size ? OPTIMIZE_SIZE_MAX : OPTIMIZE_SIZE_NO;
>>>>
>>>> We could also do (opt_for_fn (cfun->decl, optimize_size) that is
>>>> probably better since one can change optimize_size with optimization
>>>> attribute.
>>>
>>> Good point, agree!
>>>
>>>> However I think in most cases we check for optimize_size early I think
>>>> we are doing something wrong, since at that time htere is no profile
>>>> available.  Why exactly PR105818 hits the flag change issue?
>>>
>>> For PR105818, the reason why the flag changs is that:
>>>
>>> Firstly, the inconsistent flag is OPTION_MASK_SAVE_TOC_INDIRECT bit
>>> of rs6000_isa_flags_explicit, it's set as below:
>>>
>>> /* If we can shrink-wrap the TOC register save separately, then use
>>>    -msave-toc-indirect unless explicitly disabled.  */
>>> if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
>>>     && flag_shrink_wrap_separate
>>>     && optimize_function_for_speed_p (cfun))
>>>   rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
>>>
>>> Initially, rs6000 initialize target_option_default_node with
>>> OPTION_MASK_SAVE_TOC_INDIRECT unset, at that time cfun is NULL
>>> and optimize_size is true.
>>>
>>> Later, when c parser handling function foo, it builds target
>>> option node as target_option_default_node in function
>>> handle_optimize_attribute, it does global option saving and
>>> verifying there as well, at that time the cfun is NULL, no
>>> issue is found.  And function store_parm_decls allocates
>>> struct_function for foo then, cfun becomes function struct
>>> for foo, when c parser continues to handle the decl bar in
>>> foo, function handle_optimize_attribute works as before,
>>> tries to restore the target options at the end, it calls
>>> targetm.target_option.restore (rs6000_function_specific_restore)
>>> which calls function rs6000_option_override_internal again,
>>> at this time the cfun is not NULL while there is no cgraph
>>> node for its decl, optimize_function_for_speed_p returns true
>>> and gets the OPTION_MASK_SAVE_TOC_INDIRECT bit of flag
>>> rs6000_isa_flags set unexpectedly.  It becomes inconsistent
>>> as the one saved previously.
>>>
>>> IMHO, both contexts of global and function decl foo here hold
>>> optimize_size, function optimize_function_for_speed_p should
>>> not return true anyway.
>>>
>>> btw, the aarch64 failed case also gets the unexpected
>>> result for optimize_function_for_speed_p during c parsing
>>> (fold_range_test <- ... <- c_parser_condition).
>>>
>>> IIUC, in parsing time we don't have the profile information
>>> available.
>>>
>>
>> Hi Honza,
>>
>> Does the above explanation sound reasonable to you?
>>
> 

Hi Honza,

Gentle ping again ...

BR,
Kewen

  reply	other threads:[~2022-08-29  6:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14  7:57 Kewen.Lin
2022-06-14 11:37 ` Jan Hubicka
2022-06-15  6:20   ` Kewen.Lin
2022-07-11  3:42     ` Kewen.Lin
2022-08-15  8:33       ` Kewen.Lin
2022-08-29  6:35         ` Kewen.Lin [this message]
2022-09-28  5:46           ` Kewen.Lin
2022-06-14 12:53 ` Segher Boessenkool
2022-06-15  6:21   ` Kewen.Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5404908f-76d9-8898-3621-1f54064892fb@linux.ibm.com \
    --to=linkw@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@kam.mff.cuni.cz \
    --cc=hubicka@ucw.cz \
    --cc=richard.guenther@gmail.com \
    --cc=richard.sandiford@arm.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).