An problematic interaction between a call created by gimple_build_call and inlining

An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock]

I'm trying to generate calls to "free" on the fly at ipa time.

I've tried several things (given below) but they both fail
in expand_call_inline in tree-inline.c on this gcc_checking_assert:

  cg_edge = id->dst_node->get_edge (stmt);
  gcc_checking_assert (cg_edge);

Now, I've tried using the built in free via:

  tree fndecl_free = builtin_decl_explicit( BUILT_IN_FREE);
  // Note to_free is set between here and the call by an assign
  tree to_free =
    make_temp_ssa_name( reorg_pointer_type, NULL, "malloc_to_free");
  .
  .
  gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);

or building the fndecl from scrath:

  tree fntype = build_function_type ( free_return_type, param_type_list);
  tree fnname = get_identifier ( "free");
  tree fndecl_free =
    build_decl ( input_location, FUNCTION_DECL, fnname, fntype);
  gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);

Note, I was able to get something similar to work for "malloc" by
using the fndecl I extracted from an existing malloc call.

Your advice on how to build a fndecl that doesn't have this
problem is appreciated.

Thanks,

Gary Oblock


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 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: An problematic interaction between a call created by gimple_build_call and inlining

[Richard Biener]

On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote:
>
> I'm trying to generate calls to "free" on the fly at ipa time.
>
> I've tried several things (given below) but they both fail
> in expand_call_inline in tree-inline.c on this gcc_checking_assert:
>
>   cg_edge = id->dst_node->get_edge (stmt);
>   gcc_checking_assert (cg_edge);

It simply means you are operating at a point where we expect
callgraph edges to be present but you fail to update the callgraph
for your added function call.  it might be as easy as calling

cgraph_node::get (cfun->decl)->create_edge (cgraph_node::get_create
(fndecl_free), free_call, gimple_bb (free_call)->count);

> Now, I've tried using the built in free via:
>
>   tree fndecl_free = builtin_decl_explicit( BUILT_IN_FREE);
>   // Note to_free is set between here and the call by an assign
>   tree to_free =
>     make_temp_ssa_name( reorg_pointer_type, NULL, "malloc_to_free");
>   .
>   .
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> or building the fndecl from scrath:
>
>   tree fntype = build_function_type ( free_return_type, param_type_list);
>   tree fnname = get_identifier ( "free");
>   tree fndecl_free =
>     build_decl ( input_location, FUNCTION_DECL, fnname, fntype);
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> Note, I was able to get something similar to work for "malloc" by
> using the fndecl I extracted from an existing malloc call.
>
> Your advice on how to build a fndecl that doesn't have this
> problem is appreciated.
>
> Thanks,
>
> Gary Oblock
>
>
> 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 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: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock]

Thank you Richard.

I feel a bit dumb because I'm well aware of the GCC philosophy to have
any new code produced update the state.  Of course I didn't know the
commands to do this for the call graph (which I really appreciate you giving.)

However, the real reason I'm sending a reply is this. Are there any surprising
cases in IPA where GCC violates its philosophy and actually regenerates the
information?

Thanks again,

Gary

________________________________
From: Richard Biener <richard.guenther@gmail.com>
Sent: Wednesday, July 1, 2020 12:27 AM
To: Gary Oblock <gary@amperecomputing.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining

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


On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote:
>
> I'm trying to generate calls to "free" on the fly at ipa time.
>
> I've tried several things (given below) but they both fail
> in expand_call_inline in tree-inline.c on this gcc_checking_assert:
>
>   cg_edge = id->dst_node->get_edge (stmt);
>   gcc_checking_assert (cg_edge);

It simply means you are operating at a point where we expect
callgraph edges to be present but you fail to update the callgraph
for your added function call.  it might be as easy as calling

cgraph_node::get (cfun->decl)->create_edge (cgraph_node::get_create
(fndecl_free), free_call, gimple_bb (free_call)->count);

> Now, I've tried using the built in free via:
>
>   tree fndecl_free = builtin_decl_explicit( BUILT_IN_FREE);
>   // Note to_free is set between here and the call by an assign
>   tree to_free =
>     make_temp_ssa_name( reorg_pointer_type, NULL, "malloc_to_free");
>   .
>   .
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> or building the fndecl from scrath:
>
>   tree fntype = build_function_type ( free_return_type, param_type_list);
>   tree fnname = get_identifier ( "free");
>   tree fndecl_free =
>     build_decl ( input_location, FUNCTION_DECL, fnname, fntype);
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> Note, I was able to get something similar to work for "malloc" by
> using the fndecl I extracted from an existing malloc call.
>
> Your advice on how to build a fndecl that doesn't have this
> problem is appreciated.
>
> Thanks,
>
> Gary Oblock
>
>
> 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 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: An problematic interaction between a call created by gimple_build_call and inlining

[Martin Jambor]

Hi,

On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
> Thank you Richard.
>
> I feel a bit dumb because I'm well aware of the GCC philosophy to have
> any new code produced update the state.  Of course I didn't know the
> commands to do this for the call graph (which I really appreciate you giving.)
>
> However, the real reason I'm sending a reply is this. Are there any surprising
> cases in IPA where GCC violates its philosophy and actually regenerates the
> information?

if by "the information" you specifically mean call graph edges then no.
(Regular) IPA optimizations are designed to also work when doing link
time optimization (LTO) which means that unless they specifically load
the (gimple) bodies of some selected functions, the bodies are not
available to them.  They only operate on the call graph and information
they collected when generating summaries.  Because gimple body is not
available, call graph edges cannot be regenerated from it.

In fact, when a call is redirected to a different/specialized function,
at IPA time it is only recored in the call graph by redirecting the
corresponding edge and the call statement is modified only at the end of
IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
using LTO because until specialized nodes get their own body, they share
it with the node from which they were cloned.  That means that several
call graph edges, which do not share caller and may not even share the
callee, refer to the same gimple statement - so the decl in the
statement is actually meaningless and the edge encodes the important
information.

Martin

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock]

Martin,

What about immediate dominators?

Thanks,

Gary

________________________________
From: Martin Jambor <mjambor@suse.cz>
Sent: Wednesday, July 1, 2020 3:40 PM
To: Gary Oblock <gary@amperecomputing.com>; Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining

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


Hi,

On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
> Thank you Richard.
>
> I feel a bit dumb because I'm well aware of the GCC philosophy to have
> any new code produced update the state.  Of course I didn't know the
> commands to do this for the call graph (which I really appreciate you giving.)
>
> However, the real reason I'm sending a reply is this. Are there any surprising
> cases in IPA where GCC violates its philosophy and actually regenerates the
> information?

if by "the information" you specifically mean call graph edges then no.
(Regular) IPA optimizations are designed to also work when doing link
time optimization (LTO) which means that unless they specifically load
the (gimple) bodies of some selected functions, the bodies are not
available to them.  They only operate on the call graph and information
they collected when generating summaries.  Because gimple body is not
available, call graph edges cannot be regenerated from it.

In fact, when a call is redirected to a different/specialized function,
at IPA time it is only recored in the call graph by redirecting the
corresponding edge and the call statement is modified only at the end of
IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
using LTO because until specialized nodes get their own body, they share
it with the node from which they were cloned.  That means that several
call graph edges, which do not share caller and may not even share the
callee, refer to the same gimple statement - so the decl in the
statement is actually meaningless and the edge encodes the important
information.

Martin

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Martin Jambor]

Hi,

On Thu, Jul 02 2020, Gary Oblock wrote:
> Martin,
>
> What about immediate dominators?

I'm afraid I don't understand your question, what about them?

Dominators are re-computed after inlining and after clones are
materialized (when they get their own body)... I believe.

We do not store information which call graph edges dominate other call
graph edges in the callers body.  Having that information might be
useful at IPA stage.

But yeah, please be more specific what your question is.

Martin

>
> ________________________________
> From: Martin Jambor <mjambor@suse.cz>
> Sent: Wednesday, July 1, 2020 3:40 PM
> To: Gary Oblock <gary@amperecomputing.com>; Richard Biener <richard.guenther@gmail.com>
> Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
> Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>
>
> Hi,
>
> On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
>> Thank you Richard.
>>
>> I feel a bit dumb because I'm well aware of the GCC philosophy to have
>> any new code produced update the state.  Of course I didn't know the
>> commands to do this for the call graph (which I really appreciate you giving.)
>>
>> However, the real reason I'm sending a reply is this. Are there any surprising
>> cases in IPA where GCC violates its philosophy and actually regenerates the
>> information?
>
> if by "the information" you specifically mean call graph edges then no.
> (Regular) IPA optimizations are designed to also work when doing link
> time optimization (LTO) which means that unless they specifically load
> the (gimple) bodies of some selected functions, the bodies are not
> available to them.  They only operate on the call graph and information
> they collected when generating summaries.  Because gimple body is not
> available, call graph edges cannot be regenerated from it.
>
> In fact, when a call is redirected to a different/specialized function,
> at IPA time it is only recored in the call graph by redirecting the
> corresponding edge and the call statement is modified only at the end of
> IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
> using LTO because until specialized nodes get their own body, they share
> it with the node from which they were cloned.  That means that several
> call graph edges, which do not share caller and may not even share the
> callee, refer to the same gimple statement - so the decl in the
> statement is actually meaningless and the edge encodes the important
> information.
>
> Martin

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock]

Martin,

Actually it's basic blocks that dominate on another though I suppose you could generalize the notion to CFG edges but to what point?

I'm seeing in some of the code that I read, immediate dominators being manually computed and added to the BBs at their point of creation. At the moment I'm punting on creating them hoping I don't create an untenable state which results in hard to diagnose failures. I was just trying to avoid this.

Thanks,

Gary Oblock

________________________________
From: Martin Jambor <mjambor@suse.cz>
Sent: Friday, July 3, 2020 1:59 AM
To: Gary Oblock <gary@amperecomputing.com>; Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining

Hi,

On Thu, Jul 02 2020, Gary Oblock wrote:
> Martin,
>
> What about immediate dominators?

I'm afraid I don't understand your question, what about them?

Dominators are re-computed after inlining and after clones are
materialized (when they get their own body)... I believe.

We do not store information which call graph edges dominate other call
graph edges in the callers body.  Having that information might be
useful at IPA stage.

But yeah, please be more specific what your question is.

Martin

>
> ________________________________
> From: Martin Jambor <mjambor@suse.cz>
> Sent: Wednesday, July 1, 2020 3:40 PM
> To: Gary Oblock <gary@amperecomputing.com>; Richard Biener <richard.guenther@gmail.com>
> Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
> Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>
>
> Hi,
>
> On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
>> Thank you Richard.
>>
>> I feel a bit dumb because I'm well aware of the GCC philosophy to have
>> any new code produced update the state.  Of course I didn't know the
>> commands to do this for the call graph (which I really appreciate you giving.)
>>
>> However, the real reason I'm sending a reply is this. Are there any surprising
>> cases in IPA where GCC violates its philosophy and actually regenerates the
>> information?
>
> if by "the information" you specifically mean call graph edges then no.
> (Regular) IPA optimizations are designed to also work when doing link
> time optimization (LTO) which means that unless they specifically load
> the (gimple) bodies of some selected functions, the bodies are not
> available to them.  They only operate on the call graph and information
> they collected when generating summaries.  Because gimple body is not
> available, call graph edges cannot be regenerated from it.
>
> In fact, when a call is redirected to a different/specialized function,
> at IPA time it is only recored in the call graph by redirecting the
> corresponding edge and the call statement is modified only at the end of
> IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
> using LTO because until specialized nodes get their own body, they share
> it with the node from which they were cloned.  That means that several
> call graph edges, which do not share caller and may not even share the
> callee, refer to the same gimple statement - so the decl in the
> statement is actually meaningless and the edge encodes the important
> information.
>
> Martin