gsi_remove on a call

gsi_remove on a call

[Gary Oblock]

I'm running into grief in verify_node in cgraph.c
when I use gsi_remove on a call statement.

Specifically it's a free statement which I've replaced
with other free statements as part of my structure
reorg optimizations. Note, in other working code
I do this with malloc and it doesn't seem to be a problem.

Where it happens it's trying to look at the call graph edges.
Is there a way to remove the edge in question or mark it
to be ignored? I see that line below about built in unreachable
and wonder if I'm supposed to set the decl to that but I
don't see others doing it so...

Here's the code in cgraph (e->call_stmt is the free in question:)

 if (gimple_has_body_p (e->caller->decl)
     && !e->caller->inlined_to
     && !e->speculative
     /* Optimized out calls are redirected to __builtin_unreachable.  */
     && (e->count.nonzero_p ()
     || ! e->callee->decl
     || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
     && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
    && (!e->count.ipa_p ()
     && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
       {
          :

Thanks,

Gary






CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any unauthorized review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Re: gsi_remove on a call

[Martin Jambor]

On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_node in cgraph.c
> when I use gsi_remove on a call statement.
>
> Specifically it's a free statement which I've replaced
> with other free statements as part of my structure
> reorg optimizations. Note, in other working code
> I do this with malloc and it doesn't seem to be a problem.
>
> Where it happens it's trying to look at the call graph edges.
> Is there a way to remove the edge in question or mark it
> to be ignored?

Have you tried using cgraph_edge::set_call_stmt to update the edge?

> I see that line below about built in unreachable
> and wonder if I'm supposed to set the decl to that but I
> don't see others doing it so...

The comment you quoted explains why __builtin_unreachable is special.

Martin

>
> Here's the code in cgraph (e->call_stmt is the free in question:)
>
>  if (gimple_has_body_p (e->caller->decl)
>      && !e->caller->inlined_to
>      && !e->speculative
>      /* Optimized out calls are redirected to __builtin_unreachable.  */
>      && (e->count.nonzero_p ()
>      || ! e->callee->decl
>      || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
>      && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
>     && (!e->count.ipa_p ()
>      && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
>        {
>           :
>
> Thanks,
>
> Gary
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any unauthorized review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Re: gsi_remove on a call

[Gary Oblock]

Martin,

After some digging and a little luck, I found that this does what I wanted:

cgraph_update_edges_for_call_stmt ( stmt, gimple_call_fndecl ( stmt), NULL);

Thanks,

Gary
________________________________
From: Martin Jambor <mjambor@suse.cz>
Sent: Tuesday, October 27, 2020 5:44 AM
To: Gary Oblock <gary@amperecomputing.com>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: Re: gsi_remove on a call

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]


On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_node in cgraph.c
> when I use gsi_remove on a call statement.
>
> Specifically it's a free statement which I've replaced
> with other free statements as part of my structure
> reorg optimizations. Note, in other working code
> I do this with malloc and it doesn't seem to be a problem.
>
> Where it happens it's trying to look at the call graph edges.
> Is there a way to remove the edge in question or mark it
> to be ignored?

Have you tried using cgraph_edge::set_call_stmt to update the edge?

> I see that line below about built in unreachable
> and wonder if I'm supposed to set the decl to that but I
> don't see others doing it so...

The comment you quoted explains why __builtin_unreachable is special.

Martin

>
> Here's the code in cgraph (e->call_stmt is the free in question:)
>
>  if (gimple_has_body_p (e->caller->decl)
>      && !e->caller->inlined_to
>      && !e->speculative
>      /* Optimized out calls are redirected to __builtin_unreachable.  */
>      && (e->count.nonzero_p ()
>      || ! e->callee->decl
>      || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
>      && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
>     && (!e->count.ipa_p ()
>      && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
>        {
>           :
>
> Thanks,
>
> Gary
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any unauthorized review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.