Existing tree functionality?

Existing tree functionality?

[Michael Tegtmeyer]

Hello,

Is there existing functionality somewhere to sweep a function and collect 
all externally visible variables at the tree level or do I need to roll my 
own? I've looked in tree.h and grepped around as much as I could but I 
haven't found anything obvious.

Thanks in advance,
Mike Tegtmeyer

Re: Existing tree functionality?

[Daniel Berlin]

Most of this can be found in the cgraph nodes.  The rest requires
scanning the IL.

Ken Zadeck should have code to do this.


On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
> Hello,
> 
> Is there existing functionality somewhere to sweep a function and collect 
> all externally visible variables at the tree level or do I need to roll my 
> own? I've looked in tree.h and grepped around as much as I could but I 
> haven't found anything obvious.
> 
> Thanks in advance,
> Mike Tegtmeyer

Re: Existing tree functionality?

[Daniel Berlin]

On Wed, 2005-07-06 at 08:46 -0400, Daniel Berlin wrote:
> Most of this can be found in the cgraph nodes.  The rest requires
> scanning the IL.

> Ken Zadeck should have code to do this.
> 

Oh, i assumed you were trying to work at an interprocedural level.
If you only ever care to see a single function at a time, you can just
look at the referenced_vars list.


> 
> On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
> > Hello,
> > 
> > Is there existing functionality somewhere to sweep a function and collect 
> > all externally visible variables at the tree level or do I need to roll my 
> > own? I've looked in tree.h and grepped around as much as I could but I 
> > haven't found anything obvious.
> > 
> > Thanks in advance,
> > Mike Tegtmeyer
> 

Re: Existing tree functionality?

[Michael Tegtmeyer]

Thanks-intraprocedural is all I need.

Sorry, bit new to gcc internals (coming from SUIF), is anything missing 
from referenced_vars list or is it complete? docs in tree-dfa.c state 
that it doesn't look in statement operands. Does it just collect this from 
the symbol tables?

  Mike


On Wed, 6 Jul 2005, Daniel Berlin wrote:

> On Wed, 2005-07-06 at 08:46 -0400, Daniel Berlin wrote:
>> Most of this can be found in the cgraph nodes.  The rest requires
>> scanning the IL.
>
>> Ken Zadeck should have code to do this.
>>
>
> Oh, i assumed you were trying to work at an interprocedural level.
> If you only ever care to see a single function at a time, you can just
> look at the referenced_vars list.
>
>
>>
>> On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
>>> Hello,
>>>
>>> Is there existing functionality somewhere to sweep a function and collect
>>> all externally visible variables at the tree level or do I need to roll my
>>> own? I've looked in tree.h and grepped around as much as I could but I
>>> haven't found anything obvious.
>>>
>>> Thanks in advance,
>>> Mike Tegtmeyer
>>
>
>

Re: Existing tree functionality?

[Diego Novillo]

On Wed, Jul 06, 2005 at 09:40:08AM -0400, Michael Tegtmeyer wrote:
> Thanks-intraprocedural is all I need.
> 
> Sorry, bit new to gcc internals (coming from SUIF), is anything missing 
> from referenced_vars list or is it complete? docs in tree-dfa.c state 
> that it doesn't look in statement operands. Does it just collect this from 
> the symbol tables?
> 
No.  It collects only the variables that are actually referenced
in the function body.

If you give us a few details of what you're looking for, we can
probably help you better.


Diego.

Re: Existing tree functionality?

[Daniel Berlin]

On Wed, 2005-07-06 at 09:40 -0400, Michael Tegtmeyer wrote:
> Thanks-intraprocedural is all I need.
> 
> Sorry, bit new to gcc internals (coming from SUIF), is anything missing 
> from referenced_vars list or is it complete?

It is a complete list of variables *referenced from this function*.

>  docs in tree-dfa.c state 
> that it doesn't look in statement operands. 

It says "doesn't look *for* statement operands", not "in" :).

It means it doesn't use the operand iterator interface we have, it
simply walks the entire tree structure recursively and just looks for
variables.

Re: Existing tree functionality?

[Kenneth Zadeck]

I hope to have my code checked in today. 
Look in ipa-reference.c

Kenny

Daniel Berlin wrote:
>Most of this can be found in the cgraph nodes.  The rest requires
>scanning the IL.
>
>Ken Zadeck should have code to do this.
>
>
>On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
>  
>>Hello,
>>
>>Is there existing functionality somewhere to sweep a function and collect 
>>all externally visible variables at the tree level or do I need to roll my 
>>own? I've looked in tree.h and grepped around as much as I could but I 
>>haven't found anything obvious.
>>
>>Thanks in advance,
>>Mike Tegtmeyer
>>    

Re: Existing tree functionality?

[Diego Novillo]

On Wed, Jul 06, 2005 at 08:32:38AM -0400, Michael Tegtmeyer wrote:

> Is there existing functionality somewhere to sweep a function and collect 
> all externally visible variables at the tree level or do I need to roll my 
> own? I've looked in tree.h and grepped around as much as I could but I 
> haven't found anything obvious.
> 
Referenced variables are collected by tree-dfa.c:find_referenced_vars.
Once collected, you can distinguish locals from globals with
is_global_var().


Diego.

Re: Existing tree functionality?

[Michael Tegtmeyer]

I'm using gcc initially to do some static analysis with the resuts being 
sent somewhere else for the time being. I basically just need to gather 
the variables with visibility outside of the current function. In addition 
I need as little tree transformation prior to this collection as 
possible-ie introduction of new temporaries etc. I scheduled a new pass 
before pass_all_optimizations that simply has pass_referenced_vars and 
pass_foo as subpasses where pass_foo does the analysis (simply calls 
debug_referenced_vars() for the moment). Things seem to work for the most 
part but I'm getting crashes for non-trivial code-mostly templates-that 
otherwise compiles fine. Am I missing something? Does something else need 
to be scheduled before pass_reference_vars? I'm using the release version 
of gcc-4 because I didn't feel like chasing a moving target but is this a 
known issue where I should be building against the snapshot?

Thanks again,
Mike Tegtmeyer

BTW Diego, I spent about a year doing OpenMP work using your CSSAME 
library. Small world eh?

>> Thanks-intraprocedural is all I need.
>>
>> Sorry, bit new to gcc internals (coming from SUIF), is anything missing
>> from referenced_vars list or is it complete? docs in tree-dfa.c state
>> that it doesn't look in statement operands. Does it just collect this 
>from
>> the symbol tables?
>>
>No.  It collects only the variables that are actually referenced
>in the function body.

>If you give us a few details of what you're looking for, we can
>probably help you better.
>
>
>Diego.

Re: Existing tree functionality?

[Diego Novillo]

On Thu, Jul 07, 2005 at 09:31:35AM -0400, Michael Tegtmeyer wrote:

> I'm getting crashes for non-trivial code-mostly templates-that 
> otherwise compiles fine. Am I missing something? Does something else need 
> to be scheduled before pass_reference_vars?
>
You would have to show us your patch and the failing test case.
This is too vague for me to know what may be wrong.  If you are
not modifying the IL, then it looks like your pass_foo is doing
something wonky.


Diego.

Re: Existing tree functionality?

[Daniel Berlin]

On Thu, 2005-07-07 at 09:31 -0400, Michael Tegtmeyer wrote:
> I'm using gcc initially to do some static analysis with the resuts being 
> sent somewhere else for the time being. I basically just need to gather 
> the variables with visibility outside of the current function. In addition 
> I need as little tree transformation prior to this collection as 
> possible-ie introduction of new temporaries etc. I scheduled a new pass 
> before pass_all_optimizations that simply has pass_referenced_vars and 
> pass_foo as subpasses where pass_foo does the analysis (simply calls 
> debug_referenced_vars() for the moment).

pass_init_datastructures is still necessary.
If that is being called, then it is likely your code that is doing
something broken, since, as you've said, it works fine otherwise :)

Re: Existing tree functionality?

[Michael Tegtmeyer]

> pass_init_datastructures is still necessary.

That was the problem-thanks.

New question (or still the original rather), is there existing 
functionality to obtain the variables used in a function with external 
visibility for that function-or in other words-any variable not local to 
that function? is_global_vars() works for globals but misses:

struct foo {
 	int i;
 	void bar() {i=10;}
};

In bar, 'i' is not global but is not passed in via arguments either. 
referenced_vars contains the 'this' ptr. Is there anything existing that 
will obtain 'i' as an external variable w.r.t. bar?

Thanks again,
Mike

Re: Existing tree functionality?

[Diego Novillo]

On Thu, Jul 07, 2005 at 12:40:11PM -0400, Michael Tegtmeyer wrote:

> In bar, 'i' is not global but is not passed in via arguments either. 
> referenced_vars contains the 'this' ptr. Is there anything existing that 
> will obtain 'i' as an external variable w.r.t. bar?
> 
'i' is not a standalone variable, it's a field of struct foo.
'this' is a PARM_DECL.  'this->i' is external to bar.


Diego.

Re: Existing tree functionality?

[Daniel Berlin]

On Thu, 2005-07-07 at 12:40 -0400, Michael Tegtmeyer wrote:
> > pass_init_datastructures is still necessary.
> 
> That was the problem-thanks.
> 
> New question (or still the original rather), is there existing 
> functionality to obtain the variables used in a function with external 
> visibility for that function-or in other words-any variable not local to 
> that function? is_global_vars() works for globals but misses:
> 
> struct foo {
>  	int i;
>  	void bar() {i=10;}
> };


> In bar, 'i' is not global but is not passed in via arguments either. 
> referenced_vars contains the 'this' ptr.

i is not a regular variable here, it's a member of a structure.

>  Is there anything existing that 
> will obtain 'i' as an external variable w.r.t. bar?

No, but only because it's not really a variable, it's a structure
member, and only ever accessed as such.  It thus doesn't appear as a
VAR_DECL (in gcc terms), it appears in component accesses as a
FIELD_DECL. 




> 
> Thanks again,
> Mike

Re: Existing tree functionality?

[Michael Tegtmeyer]

> struct foo {
>  	int i;
>  	void bar() {i=10;}
> };

> i is not a regular variable here, it's a member of a structure.

Agreed.

> No, but only because it's not really a variable, it's a structure
> member, and only ever accessed as such.  It thus doesn't appear as a
> VAR_DECL (in gcc terms), it appears in component accesses as a
> FIELD_DECL.

Sorry, I'm still pretty new to the tree layout. So what is the easiest way 
to access this? referenced_vars returns the 'this' variable which is 
obviously a structure. My understanding is that I can access it's fields
with the facilities available but 'i' is what was specifically 
referenced - not all of the fields. So the question is, what is the 
easiest way to obtain the specific field that was referenced in this case?

Re: Existing tree functionality?

[Diego Novillo]

On Thu, Jul 07, 2005 at 01:28:18PM -0400, Michael Tegtmeyer wrote:

> So the question is, what is the easiest way to obtain the
> specific field that was referenced in this case?
>
You need to traverse the IL and examine the LHS and RHS of
expressions for COMPONENT_REF and INDIRECT_REF expressions.  In
GIMPLE these expressions may only appear on the LHS or RHS of
assignments, and in function arguments.

You then need to walk the expression looking for FIELD_DECLs.
And you had better do this before SRA (which will decompose most
structure references into compiler generated scalars).


Diego.