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