public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Question about callgraph and call_stmt
@ 2020-10-13 11:15 Erick Ochoa
  2020-10-13 11:37 ` Richard Biener
  0 siblings, 1 reply; 4+ messages in thread
From: Erick Ochoa @ 2020-10-13 11:15 UTC (permalink / raw)
  To: GCC Development; +Cc: Christoph Müllner, Philipp Tomsich

Hi,

I am analyzing gimple calls during LTO. I found a gimple call statement 
s that has the following properties:

```
tree fndecl = gimple_call_fndecl(s)
gcc_assert(fndecl)
// That is, the gimple call returns a non-null fndecl.
cgraph_node *n = cgraph_node::get(fndecl);
gcc_assert(!n)
// That is, there is no cgraph_node for this fndecl
```

Does anyone know hot to obtain the cgraph_node in this case? Or 
alternatively, why there is no cgraph_node associated with this call 
statement? I have already tried with adding TODO_rebuild_cgraph_edges 
before running my pass but I suspect this has more to do with gimple 
than with the call graph.

Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about callgraph and call_stmt
  2020-10-13 11:15 Question about callgraph and call_stmt Erick Ochoa
@ 2020-10-13 11:37 ` Richard Biener
  2020-10-13 12:40   ` Erick Ochoa
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Biener @ 2020-10-13 11:37 UTC (permalink / raw)
  To: Erick Ochoa; +Cc: GCC Development, Philipp Tomsich, Christoph Müllner

On Tue, Oct 13, 2020 at 1:17 PM Erick Ochoa
<erick.ochoa@theobroma-systems.com> wrote:
>
> Hi,
>
> I am analyzing gimple calls during LTO.

What's symtab->state at this point?

>I found a gimple call statement
> s that has the following properties:
>
> ```
> tree fndecl = gimple_call_fndecl(s)
> gcc_assert(fndecl)
> // That is, the gimple call returns a non-null fndecl.
> cgraph_node *n = cgraph_node::get(fndecl);
> gcc_assert(!n)
> // That is, there is no cgraph_node for this fndecl
> ```
>
> Does anyone know hot to obtain the cgraph_node in this case? Or
> alternatively, why there is no cgraph_node associated with this call
> statement? I have already tried with adding TODO_rebuild_cgraph_edges
> before running my pass but I suspect this has more to do with gimple
> than with the call graph.

what's the particular fndecl?

>
> Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about callgraph and call_stmt
  2020-10-13 11:37 ` Richard Biener
@ 2020-10-13 12:40   ` Erick Ochoa
  2020-10-13 13:29     ` Richard Biener
  0 siblings, 1 reply; 4+ messages in thread
From: Erick Ochoa @ 2020-10-13 12:40 UTC (permalink / raw)
  To: Richard Biener; +Cc: GCC Development, Philipp Tomsich, Christoph Müllner



On 13/10/2020 13:37, Richard Biener wrote:
> On Tue, Oct 13, 2020 at 1:17 PM Erick Ochoa
> <erick.ochoa@theobroma-systems.com> wrote:
>>
>> Hi,
>>
>> I am analyzing gimple calls during LTO.
> 
> What's symtab->state at this point?

The state is IPA_SSA_AFTER_INLINING.

> 
>> I found a gimple call statement
>> s that has the following properties:
>>
>> ```
>> tree fndecl = gimple_call_fndecl(s)
>> gcc_assert(fndecl)
>> // That is, the gimple call returns a non-null fndecl.
>> cgraph_node *n = cgraph_node::get(fndecl);
>> gcc_assert(!n)
>> // That is, there is no cgraph_node for this fndecl
>> ```
>>
>> Does anyone know hot to obtain the cgraph_node in this case? Or
>> alternatively, why there is no cgraph_node associated with this call
>> statement? I have already tried with adding TODO_rebuild_cgraph_edges
>> before running my pass but I suspect this has more to do with gimple
>> than with the call graph.
> 
> what's the particular fndecl?

The callsite is in a function that has been inlined and specialized. The 
callsite calls a function that is not inlined but has also been 
specialized. I'll try reducing my test case a bit.

> 
>>
>> Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about callgraph and call_stmt
  2020-10-13 12:40   ` Erick Ochoa
@ 2020-10-13 13:29     ` Richard Biener
  0 siblings, 0 replies; 4+ messages in thread
From: Richard Biener @ 2020-10-13 13:29 UTC (permalink / raw)
  To: Erick Ochoa; +Cc: GCC Development, Philipp Tomsich, Christoph Müllner

On Tue, Oct 13, 2020 at 2:40 PM Erick Ochoa
<erick.ochoa@theobroma-systems.com> wrote:
>
>
>
> On 13/10/2020 13:37, Richard Biener wrote:
> > On Tue, Oct 13, 2020 at 1:17 PM Erick Ochoa
> > <erick.ochoa@theobroma-systems.com> wrote:
> >>
> >> Hi,
> >>
> >> I am analyzing gimple calls during LTO.
> >
> > What's symtab->state at this point?
>
> The state is IPA_SSA_AFTER_INLINING.
>
> >
> >> I found a gimple call statement
> >> s that has the following properties:
> >>
> >> ```
> >> tree fndecl = gimple_call_fndecl(s)
> >> gcc_assert(fndecl)
> >> // That is, the gimple call returns a non-null fndecl.
> >> cgraph_node *n = cgraph_node::get(fndecl);
> >> gcc_assert(!n)
> >> // That is, there is no cgraph_node for this fndecl
> >> ```
> >>
> >> Does anyone know hot to obtain the cgraph_node in this case? Or
> >> alternatively, why there is no cgraph_node associated with this call
> >> statement? I have already tried with adding TODO_rebuild_cgraph_edges
> >> before running my pass but I suspect this has more to do with gimple
> >> than with the call graph.
> >
> > what's the particular fndecl?
>
> The callsite is in a function that has been inlined and specialized. The
> callsite calls a function that is not inlined but has also been
> specialized. I'll try reducing my test case a bit.

So you eventually shouldn't look at bodies saved just for inlining
(node->inlined_to)

Richard.

> >
> >>
> >> Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-10-13 13:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-13 11:15 Question about callgraph and call_stmt Erick Ochoa
2020-10-13 11:37 ` Richard Biener
2020-10-13 12:40   ` Erick Ochoa
2020-10-13 13:29     ` Richard Biener

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).