From: Qing Zhao <qing.zhao@oracle.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: richard Sandiford <richard.sandiford@arm.com>,
gcc-patches Qing Zhao via <gcc-patches@gcc.gnu.org>,
kees cook <keescook@chromium.org>
Subject: Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?
Date: Thu, 1 Jul 2021 13:45:27 +0000 [thread overview]
Message-ID: <012695E0-171C-4F9A-ABCF-0FF7E8159278@oracle.com> (raw)
In-Reply-To: <CAFiYyc0m+v7g5EakgWqzbo2McVUj7GZcqO30QN6ow90Wb=NPKw@mail.gmail.com>
> On Jul 1, 2021, at 1:48 AM, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>>
>>> On Jun 30, 2021, at 1:59 PM, Richard Biener <rguenther@suse.de> wrote:
>>>
>>> On June 30, 2021 8:07:43 PM GMT+02:00, Qing Zhao <qing.zhao@oracle.com> wrote:
>>>>
>>>>
>>>>> On Jun 30, 2021, at 12:36 PM, Richard Biener <rguenther@suse.de>
>>>> wrote:
>>>>>
>>>>> On June 30, 2021 7:20:18 PM GMT+02:00, Andrew Pinski
>>>> <pinskia@gmail.com> wrote:
>>>>>> On Wed, Jun 30, 2021 at 8:47 AM Qing Zhao via Gcc-patches
>>>>>> <gcc-patches@gcc.gnu.org> wrote:
>>>>>>>
>>>>>>> I came up with a very simple testing case that can repeat the same
>>>>>> issue:
>>>>>>>
>>>>>>> [qinzhao@localhost gcc]$ cat t.c
>>>>>>> extern void bar (int);
>>>>>>> void foo (int a)
>>>>>>> {
>>>>>>> int i;
>>>>>>> for (i = 0; i < a; i++) {
>>>>>>> if (__extension__({int size2;
>>>>>>> size2 = 4;
>>>>>>> size2 > 5;}))
>>>>>>> bar (a);
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>> You should show the full dump,
>>>>>> What we have is the following:
>>>>>>
>>>>>>
>>>>>>
>>>>>> size2_3 = PHI <size2_1(D), size2_13>
>>>>>> <bb 3> :
>>>>>>
>>>>>> size2_12 = .DEFERRED_INIT (size2_3, 2);
>>>>>> size2_13 = 4;
>>>>>>
>>>>>> So CCP decides to propagate 4 into the PHI and then decides
>>>> size2_1(D)
>>>>>> is undefined so size2_3 is then considered 4 and propagates it into
>>>>>> the .DEFERRED_INIT.
>>>>>
>>>>> Which means the DEFERED_INIT is inserted at the wrong place.
>>>>
>>>> Then, where is the correct place for “.DEFERRED_INIT(size2,2)?
>>>>
>>>> The variable “size2” is a block scope variable which is declared inside
>>>> the “if” condition:
>>>
>>> But that's obviously not how it behaves
>>> During into SSA phase since we're inserting a PHI for it - and we're inserting it because of the use in the DEFERED_INIT call. I suppose you need to fiddle with the SSA rewrite and avoid treating the use as a use but only for the purpose of inserting PHIs...
>>
>> Please see my other email on the new small testing case without -ftrivial-auto-var-init. The same issue in SSA with that testing case even without -ftrivial-auto-var-init.
>> It looks like an existing bug to me in SSA.
>
> It's not a bug in SSA, it's at most a missed optimization there.
I still think that SSA cannot handle block-scoped variable correctly in this case, it should not move the variable out side of the block scope. -:)
> But
> with -ftrivial-auto-var-init it
> becomes a correctness issue. I think the idea avoiding the USE of the
> variable in .DEFERRED_INIT
> and instead passing the init size is a good one and should avoid this
> case (hopefully).
Agreed, I have made such change yesterday, and this work around the current issue.
temp = .DEFERRED_INIT (temp/WITH_SIZE_EXPR(temp), init_type)
To:
temp = .DEFERRED_INIT (SIZE_of_temp, init_type)
Thanks.
Qing
>
> Richard.
>
>> Let me know if I still miss anything
>>
>> Qing
>>>
>>> You might be able to construct a testcase which has a use before the real init where then the optimistic CCP propagation will defeat the DEFERED_INIT otherwise.
>>>
>>> I'd need to play with the actual patch to find a good solution to this problem.
>>>
>>> Richard.
>>>
>>
next prev parent reply other threads:[~2021-07-01 13:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 0:14 Qing Zhao
2021-06-30 7:46 ` Richard Biener
2021-06-30 14:04 ` Qing Zhao
2021-06-30 14:39 ` Richard Biener
2021-06-30 15:11 ` Qing Zhao
2021-06-30 15:43 ` Qing Zhao
2021-06-30 17:20 ` Andrew Pinski
2021-06-30 17:36 ` Richard Biener
2021-06-30 18:07 ` Qing Zhao
2021-06-30 18:59 ` Richard Biener
2021-06-30 19:10 ` Qing Zhao
2021-06-30 19:14 ` Qing Zhao
2021-06-30 19:20 ` Andrew Pinski
2021-06-30 19:54 ` Qing Zhao
2021-07-01 6:48 ` Richard Biener
2021-07-01 13:45 ` Qing Zhao [this message]
2021-07-01 14:04 ` Richard Biener
2021-07-01 15:27 ` Qing Zhao
2021-07-01 14:09 ` Richard Sandiford
2021-07-01 14:40 ` Michael Matz
2021-07-01 15:35 ` Richard Sandiford
2021-07-01 16:06 ` Michael Matz
2021-07-01 16:23 ` Richard Sandiford
2021-07-01 16:35 ` Qing Zhao
2021-07-01 15:42 ` Qing Zhao
2021-07-01 18:14 ` Richard Biener
2021-07-01 15:32 ` Qing Zhao
2021-06-30 19:04 ` Qing Zhao
2021-06-30 17:45 ` Qing Zhao
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=012695E0-171C-4F9A-ABCF-0FF7E8159278@oracle.com \
--to=qing.zhao@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=keescook@chromium.org \
--cc=richard.guenther@gmail.com \
--cc=richard.sandiford@arm.com \
/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).