public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin Liška" <mliska@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>,
	Andrew Pinski <pinskia@gmail.com>
Cc: Andrew Pinski <apinski@marvell.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] Fix tree-optimization/101941: IPA splitting out function with error attribute
Date: Fri, 14 Jan 2022 09:23:28 +0100	[thread overview]
Message-ID: <dbfc7222-24a6-c0b8-3391-925e11dffa1d@suse.cz> (raw)
In-Reply-To: <CAFiYyc2EQ0EA3XX98Mt3hG8gyG2MgeP+tMoVP6M6g8ceLTuxkA@mail.gmail.com>

PING^1

May I please ping this so that we can can Linux kernel as soon as possible?
We would benefit from that for GCC 12.1.0 release.

Thanks,
Martin

On 11/19/21 14:07, Richard Biener via Gcc-patches wrote:
> On Fri, Nov 19, 2021 at 12:50 PM Andrew Pinski <pinskia@gmail.com> wrote:
>>
>> On Fri, Nov 19, 2021 at 2:16 AM Richard Biener via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> On Wed, Nov 17, 2021 at 7:25 AM apinski--- via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>>
>>>> From: Andrew Pinski <apinski@marvell.com>
>>>>
>>>> The Linux kernel started to fail compile when the jump threader was improved
>>>> (r12-2591-g2e96b5f14e4025691). This failure was due to the IPA splitting code
>>>> decided now to split off the basic block which contained two functions,
>>>> one of those functions included the error attribute on them.  This patch fixes
>>>> the problem by disallowing basic blocks from being split which contain functions
>>>> that have either the error or warning attribute on them.
>>>>
>>>> The two new testcases are to make sure we still split the function for other
>>>> places if we reject the one case.
>>>
>>> Hmm, it's only problematic if the immediate(?) controlling condition of the
>>> error/warning annotated call is not in the split part, no?
>> No, if we have something like:
>>    if (p_size < 32) {
>>      if (ctx != 0) {
>>        __write_overflow();
>>     }
>>      fortify_panic(__func__);
>>   }
>> We would still run into the problem if we just disable the splitting
>> for the innermost bb and split off the 3 other bb's
>> I have a testcase where the above would fail if we decide only to make
>> sure the split point is not after ctx !=0 check.
>>
>>> Interestingly we for example don't avoid splitting away __builtin_constant_p either.
>>
>> __builtin_constant_p is handled a different way already; in
>> check_forbidden_calls we set forbidden_dominators to include the bb
>> where the builtin_constant_p would have been true.
>> And then when we consider the split, we reject if the entry point
>> would have been dominated by one of those bbs.
>> This was PR49642.
> 
> I see.  So how's error/warning different - don't we want to forbit split points
> that dominate those calls itself?
> 
>>
>>
>> Thanks,
>> Andrew Pinski
>>
>>
>>>
>>> Richard.
>>>
>>>> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>>>>
>>>>          PR tree-optimization/101941
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>>          * ipa-split.c (visit_bb): Disallow function calls where
>>>>          the function has either error or warning attribute.
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>>          * gcc.c-torture/compile/pr101941-1.c: New test.
>>>>          * gcc.dg/tree-ssa/pr101941-1.c: New test.
>>>> ---
>>>>   gcc/ipa-split.c                               | 12 ++++-
>>>>   .../gcc.c-torture/compile/pr101941-1.c        | 44 +++++++++++++++++
>>>>   gcc/testsuite/gcc.dg/tree-ssa/pr101941-1.c    | 48 +++++++++++++++++++
>>>>   3 files changed, 103 insertions(+), 1 deletion(-)
>>>>   create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr101941-1.c
>>>>   create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr101941-1.c
>>>>
>>>> diff --git a/gcc/ipa-split.c b/gcc/ipa-split.c
>>>> index c68577d04a9..070e894ef31 100644
>>>> --- a/gcc/ipa-split.c
>>>> +++ b/gcc/ipa-split.c
>>>> @@ -873,7 +873,7 @@ visit_bb (basic_block bb, basic_block return_bb,
>>>>         gimple *stmt = gsi_stmt (bsi);
>>>>         tree op;
>>>>         ssa_op_iter iter;
>>>> -      tree decl;
>>>> +      tree decl = NULL_TREE;
>>>>
>>>>         if (is_gimple_debug (stmt))
>>>>          continue;
>>>> @@ -927,6 +927,16 @@ visit_bb (basic_block bb, basic_block return_bb,
>>>>              break;
>>>>            }
>>>>
>>>> +      /* If a function call and that function has either the
>>>> +        warning or error attribute on it, don't split.  */
>>>> +      if (decl && (lookup_attribute ("warning", DECL_ATTRIBUTES (decl))
>>>> +                  || lookup_attribute ("error", DECL_ATTRIBUTES (decl))))
>>>> +       {
>>>> +         if (dump_file && (dump_flags & TDF_DETAILS))
>>>> +           fprintf (dump_file, "Cannot split: warning or error attribute.\n");
>>>> +         can_split = false;
>>>> +       }
>>>> +
>>>>         FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_DEF)
>>>>          bitmap_set_bit (set_ssa_names, SSA_NAME_VERSION (op));
>>>>         FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
>>>> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr101941-1.c b/gcc/testsuite/gcc.c-torture/compile/pr101941-1.c
>>>> new file mode 100644
>>>> index 00000000000..ab3bbea8ed7
>>>> --- /dev/null
>>>> +++ b/gcc/testsuite/gcc.c-torture/compile/pr101941-1.c
>>>> @@ -0,0 +1,44 @@
>>>> +/* { dg-additional-options "-fconserve-stack" } */
>>>> +struct crypto_aes_ctx {
>>>> +  char key_dec[128];
>>>> +};
>>>> +
>>>> +int rfc4106_set_hash_subkey_hash_subkey;
>>>> +
>>>> +void __write_overflow(void)__attribute__((__error__("")));
>>>> +void __write_overflow1(void);
>>>> +void aes_encrypt(void*);
>>>> +
>>>> +void fortify_panic(const char*) __attribute__((__noreturn__)) ;
>>>> +
>>>> +char *rfc4106_set_hash_subkey(struct crypto_aes_ctx *ctx) {
>>>> +  void *a = &ctx->key_dec[0];
>>>> +  unsigned p_size =  __builtin_object_size(a, 0);
>>>> +#ifdef __OPTIMIZE__
>>>> +  if (p_size < 16) {
>>>> +    __write_overflow1();
>>>> +    fortify_panic(__func__);
>>>> +  }
>>>> +  if (p_size < 32) {
>>>> +    __write_overflow();
>>>> +    fortify_panic(__func__);
>>>> +  }
>>>> +#endif
>>>> +  aes_encrypt(ctx);
>>>> +  return ctx->key_dec;
>>>> +}
>>>> +
>>>> +char *(*gg)(struct crypto_aes_ctx *) = rfc4106_set_hash_subkey;
>>>> +
>>>> +void a(void)
>>>> +{
>>>> +  struct crypto_aes_ctx ctx;
>>>> +  rfc4106_set_hash_subkey(&ctx);
>>>> +}
>>>> +void b(void)
>>>> +{
>>>> +  struct crypto_aes_ctx ctx;
>>>> +  ctx.key_dec[0] = 0;
>>>> +  rfc4106_set_hash_subkey(&ctx);
>>>> +}
>>>> +
>>>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr101941-1.c b/gcc/testsuite/gcc.dg/tree-ssa/pr101941-1.c
>>>> new file mode 100644
>>>> index 00000000000..21c1d1ec466
>>>> --- /dev/null
>>>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr101941-1.c
>>>> @@ -0,0 +1,48 @@
>>>> +/* { dg-do compile } */
>>>> +/* { dg-options "-O2 -fconserve-stack -fdump-tree-optimized" } */
>>>> +struct crypto_aes_ctx {
>>>> +  char key_dec[128];
>>>> +};
>>>> +
>>>> +int rfc4106_set_hash_subkey_hash_subkey;
>>>> +
>>>> +void __write_overflow(void)__attribute__((__error__("")));
>>>> +void __write_overflow1(void);
>>>> +void aes_encrypt(void*);
>>>> +
>>>> +void fortify_panic(const char*) __attribute__((__noreturn__)) ;
>>>> +
>>>> +char *rfc4106_set_hash_subkey(struct crypto_aes_ctx *ctx) {
>>>> +  void *a = &ctx->key_dec[0];
>>>> +  unsigned p_size =  __builtin_object_size(a, 0);
>>>> +#ifdef __OPTIMIZE__
>>>> +  if (p_size < 16) {
>>>> +    __write_overflow1();
>>>> +    fortify_panic(__func__);
>>>> +  }
>>>> +  if (p_size < 32) {
>>>> +    __write_overflow();
>>>> +    fortify_panic(__func__);
>>>> +  }
>>>> +#endif
>>>> +  aes_encrypt(ctx);
>>>> +  return ctx->key_dec;
>>>> +}
>>>> +
>>>> +char *(*gg)(struct crypto_aes_ctx *) = rfc4106_set_hash_subkey;
>>>> +
>>>> +void a(void)
>>>> +{
>>>> +  struct crypto_aes_ctx ctx;
>>>> +  rfc4106_set_hash_subkey(&ctx);
>>>> +}
>>>> +void b(void)
>>>> +{
>>>> +  struct crypto_aes_ctx ctx;
>>>> +  ctx.key_dec[0] = 0;
>>>> +  rfc4106_set_hash_subkey(&ctx);
>>>> +}
>>>> +
>>>> +/* This testcase should still split out one of the above basic blocks dealing
>>>> +   with __write_overflow. */
>>>> +/* { dg-final { scan-tree-dump-times "Function rfc4106_set_hash_subkey.part" 1 "optimized" } } */
>>>> --
>>>> 2.17.1
>>>>


  reply	other threads:[~2022-01-14  8:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17  6:24 apinski
2021-11-19 10:15 ` Richard Biener
2021-11-19 11:50   ` Andrew Pinski
2021-11-19 13:07     ` Richard Biener
2022-01-14  8:23       ` Martin Liška [this message]
2022-01-14  8:41         ` Jan Hubicka
2022-01-17 18:35           ` Jakub Jelinek
2022-01-18  5:08             ` Andrew Pinski
2022-01-18  8:18               ` Jakub Jelinek
2022-01-18 10:34 apinski

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=dbfc7222-24a6-c0b8-3391-925e11dffa1d@suse.cz \
    --to=mliska@suse.cz \
    --cc=apinski@marvell.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=pinskia@gmail.com \
    --cc=richard.guenther@gmail.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).