Beginner: Declarations do not show up when iterating through Gimple stmts

Beginner: Declarations do not show up when iterating through Gimple stmts

[Jeff Saremi]

I wanted to go through declarations in a function and print them out so as to get more familiar with them before being able to manipulate them.
I wrote this function as a plugin; it successfully writes out all statements but mysteriouslty the declarations are missing. What am I missing? Is there a different way to iterate through declarations? 
thanks
jeff

static tree my_walk_stmt(gimple_stmt_iterator *gsi, bool *oprnds_handled, struct walk_stmt_info *stmt_info)
{
	int code;
	gimple stmt = gsi_stmt(*gsi);
	code = gimple_code(stmt);
	switch(code)
	{
	default:
		printf("Gimple code = %s\n", gimple_code_name[code]);
		break;
	}
	*oprnds_handled = true;
	return NULL_TREE;
}
static unsigned int execute_var_alias(void)
{
    gimple_stmt_iterator gsi;
    gimple_seq seq;
    seq = gimple_body(current_function_decl);
    for (gsi = gsi_start(seq); !gsi_end_p(gsi); gsi_next(&gsi))
    {
        gimple stmt = gsi_stmt(gsi);
        walk_gimple_stmt(&gsi, my_walk_stmt, NULL, NULL);
    }
}

Re: Beginner: Declarations do not show up when iterating through Gimple stmts

[Richard Guenther]

On Thu, Aug 26, 2010 at 3:18 AM, Jeff Saremi <jeffsaremi@yahoo.com> wrote:
> I wanted to go through declarations in a function and print them out so as to get more familiar with them before being able to manipulate them.
> I wrote this function as a plugin; it successfully writes out all statements but mysteriouslty the declarations are missing. What am I missing? Is there a different way to iterate through declarations?

There are no declaration statements in gimple.

Richard.

> thanks
> jeff
>
> static tree my_walk_stmt(gimple_stmt_iterator *gsi, bool *oprnds_handled, struct walk_stmt_info *stmt_info)
> {
>        int code;
>        gimple stmt = gsi_stmt(*gsi);
>        code = gimple_code(stmt);
>        switch(code)
>        {
>        default:
>                printf("Gimple code = %s\n", gimple_code_name[code]);
>                break;
>        }
>        *oprnds_handled = true;
>        return NULL_TREE;
> }
> static unsigned int execute_var_alias(void)
> {
>    gimple_stmt_iterator gsi;
>    gimple_seq seq;
>    seq = gimple_body(current_function_decl);
>    for (gsi = gsi_start(seq); !gsi_end_p(gsi); gsi_next(&gsi))
>    {
>        gimple stmt = gsi_stmt(gsi);
>        walk_gimple_stmt(&gsi, my_walk_stmt, NULL, NULL);
>    }
> }
>
>

Re: Beginner: Declarations do not show up when iterating through Gimple stmts

[Jeff Saremi]

well, that explains it nicely. thanks

Guidance needed: hi-level steps to track an object until its destruction

[Jeff Saremi]

I'm hoping someone here could take the time to outline what I need to do (i'm not looking for code but if you point me to some i'd appreciate it).

I'd like to track an object from the it's created until it's destroyed (in C++). And then see if a certain method of it is called or not. To keep it short we can limit this to one function at the beginning of which an object gets created and at the end of it the object goes out of scope.
And i'm guessing this can be done via one a pass at the right time. I guess before gimplification or being converted to RTL and such.

Any input's appreciated.
thanks
jeff

Re: Guidance needed: hi-level steps to track an object until its destruction

[Basile Starynkevitch]

On Thu, 2010-08-26 at 18:16 -0700, Jeff Saremi wrote:
> I'm hoping someone here could take the time to outline what I need to do (i'm not looking for code but if you point me to some i'd appreciate it).
> 
> I'd like to track an object from the it's created until it's destroyed (in C++). And then see if a certain method of it is called or not. To keep it short we can limit this to one function at the beginning of which an object gets created and at the end of it the object goes out of scope.
> And i'm guessing this can be done via one a pass at the right time. I guess before gimplification or being converted to RTL and such.


I am not sure that is easily feasible. I would believe it is impossible.

Within the compiler (or inside a GCC plugin, or inside a GCC extension
coded in MELT), you probably are able change/inspect C++ classes & every
other declaration any compiler is tracking. You are also able to find
every occurrence of variables containing a pointer to such classes.

However, you are apparently willing to track a single *instance* of such
a class, and this instance is in the execution of the compiled program
[not inside the compiler]. This means that you are able to deal with all
the aliasing & pointer equivalence issues (a task known to be
impossible). How can the compiler surely know that pointer p in [a
particular instruction of] method YourClass::foo() is never (or
sometimes, or always) pointing to the same instance -in the running
process of the compiled program- as pointer q in method yourclass::bar()

Or perhaps my English is so weak that I misunderstood you. If that is
the case, apologies.

Or maybe you want to instrument your compiler so that for every code
emitted for method yourclass::gee() you add a first block which checks
that the this reciever is not a given pointer.

In other words & C++ parlance, you could (this is doable, but not
trivial) hack the compiler so that at the start of every method (i.e.
member function in C++) the equivalent of the following C++ code has
been magically added

  extern "C" YourClass* hunted_yourclass_pointer;
  extern "C" void some_error_routine(void);

  if (this == hunted_yourclass_pointer) 
    some_error_routine();

But I am not sure you want to do that.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Guidance needed: hi-level steps to track an object until its destruction

[Jeff Saremi]

Basile,
you fully understood what I was asking. And I think I understood that I may have to rethink what I wanted to do since the effort is seemingly out-weighing the benefits.
thanks again.
jeff

--- On Sat, 8/28/10, Basile Starynkevitch <basile@starynkevitch.net> wrote:

> From: Basile Starynkevitch <basile@starynkevitch.net>
> Subject: Re: Guidance needed: hi-level steps to track an object until its destruction
> To: "Jeff Saremi" <jeffsaremi@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Received: Saturday, August 28, 2010, 1:05 PM
> On Thu, 2010-08-26 at 18:16 -0700,
> Jeff Saremi wrote:
> > I'm hoping someone here could take the time to outline
> what I need to do (i'm not looking for code but if you point
> me to some i'd appreciate it).
> > 
> > I'd like to track an object from the it's created
> until it's destroyed (in C++). And then see if a certain
> method of it is called or not. To keep it short we can limit
> this to one function at the beginning of which an object
> gets created and at the end of it the object goes out of
> scope.
> > And i'm guessing this can be done via one a pass at
> the right time. I guess before gimplification or being
> converted to RTL and such.
> 
> 
> I am not sure that is easily feasible. I would believe it
> is impossible.
> 
> Within the compiler (or inside a GCC plugin, or inside a
> GCC extension
> coded in MELT), you probably are able change/inspect C++
> classes & every
> other declaration any compiler is tracking. You are also
> able to find
> every occurrence of variables containing a pointer to such
> classes.
> 
> However, you are apparently willing to track a single
> *instance* of such
> a class, and this instance is in the execution of the
> compiled program
> [not inside the compiler]. This means that you are able to
> deal with all
> the aliasing & pointer equivalence issues (a task known
> to be
> impossible). How can the compiler surely know that pointer
> p in [a
> particular instruction of] method YourClass::foo() is never
> (or
> sometimes, or always) pointing to the same instance -in the
> running
> process of the compiled program- as pointer q in method
> yourclass::bar()
> 
> Or perhaps my English is so weak that I misunderstood you.
> If that is
> the case, apologies.
> 
> Or maybe you want to instrument your compiler so that for
> every code
> emitted for method yourclass::gee() you add a first block
> which checks
> that the this reciever is not a given pointer.
> 
> In other words & C++ parlance, you could (this is
> doable, but not
> trivial) hack the compiler so that at the start of every
> method (i.e.
> member function in C++) the equivalent of the following C++
> code has
> been magically added
> 
>   extern "C" YourClass* hunted_yourclass_pointer;
>   extern "C" void some_error_routine(void);
> 
>   if (this == hunted_yourclass_pointer) 
>     some_error_routine();
> 
> But I am not sure you want to do that.
> 
> Cheers.
> -- 
> Basile STARYNKEVITCH     
>    http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile:
> +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes}
> ***
> 
>

Re: Guidance needed: hi-level steps to track an object until its destruction

[Uday P. Khedker]

> I am not sure that is easily feasible. I would believe it is impossible.
>
> Within the compiler (or inside a GCC plugin, or inside a GCC extension
> coded in MELT), you probably are able change/inspect C++ classes&  every
> other declaration any compiler is tracking. You are also able to find
> every occurrence of variables containing a pointer to such classes.

>
> However, you are apparently willing to track a single *instance* of such
> a class, and this instance is in the execution of the compiled program
> [not inside the compiler]. This means that you are able to deal with all


To put it in other words: Here the issue is seeking runtime information at
compile time. An object is a run time entity. At compile time, we only see
the class. However, we also see the statements that create an object and
manipulate it. Although it is not possible to track each object distinctly,
a compile time approximation is certainly possible. And that is where creativity
in compiler research lies. The better the approximations, the better the gains.
For example, all objects that get created by a given statement can be treated
alike. There is no way of distinguishing between them at compile time, but perhaps
there is no need to do so because all of them are likely to be treated alike
at run time. if an object O1 and O2 are created by the same statement, asking
the question whether a method m1 is invoked for O1 does not need us to distinguish
between O1 and O2.

To summarize, a good approximation is indeed possible at compile time.


> the aliasing&  pointer equivalence issues (a task known to be
> impossible). How can the compiler surely know that pointer p in [a
> particular instruction of] method YourClass::foo() is never (or
> sometimes, or always) pointing to the same instance -in the running
> process of the compiled program- as pointer q in method yourclass::bar()

Basile, you keep mentioning that English is not your first language and I
appreciate your politeness for reminding the reader for that (English is not
the first language for me too). It is in that light that I would like to point
out that your use of word "impossible" is a little too strong. Perhaps you mean
difficult. It is impossible if you want exact information. However, if
imprecisions can be tolerated for some gains, excellent approximations are
possible _within_ a procedure body which is what Jeff asked for, to begin with.

We have been working on this problem (pointer analysis) for a while but
are quite far from production implementation. Our ideas now seem to mature
a bit and whenever we have a conference paper, I will be happy to share it
with the gcc folks.

> Or maybe you want to instrument your compiler so that for every code
> emitted for method yourclass::gee() you add a first block which checks
> that the this reciever is not a given pointer.
>
> In other words&  C++ parlance, you could (this is doable, but not
> trivial) hack the compiler so that at the start of every method (i.e.
> member function in C++) the equivalent of the following C++ code has
> been magically added
>
>    extern "C" YourClass* hunted_yourclass_pointer;
>    extern "C" void some_error_routine(void);
>
>    if (this == hunted_yourclass_pointer)
>      some_error_routine();

This is a very good way of paraphrasing the "ideal" requirement.

Regards,

Uday.

Re: Guidance needed: hi-level steps to track an object until its destruction

[J Decker]

Just out of curiosity - isn't this what C# does with objects?  would
it perhaps be something like that in how mcs (mono) builds objects and
tracks their lifespan?

On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker <uday@cse.iitb.ac.in> wrote:
>
>> I am not sure that is easily feasible. I would believe it is impossible.
>>
>> Within the compiler (or inside a GCC plugin, or inside a GCC extension
>> coded in MELT), you probably are able change/inspect C++ classes&  every
>> other declaration any compiler is tracking. You are also able to find
>> every occurrence of variables containing a pointer to such classes.
>
>>
>> However, you are apparently willing to track a single *instance* of such
>> a class, and this instance is in the execution of the compiled program
>> [not inside the compiler]. This means that you are able to deal with all
>
>
> To put it in other words: Here the issue is seeking runtime information at
> compile time. An object is a run time entity. At compile time, we only see
> the class. However, we also see the statements that create an object and
> manipulate it. Although it is not possible to track each object distinctly,
> a compile time approximation is certainly possible. And that is where
> creativity
> in compiler research lies. The better the approximations, the better the
> gains.
> For example, all objects that get created by a given statement can be
> treated
> alike. There is no way of distinguishing between them at compile time, but
> perhaps
> there is no need to do so because all of them are likely to be treated alike
> at run time. if an object O1 and O2 are created by the same statement,
> asking
> the question whether a method m1 is invoked for O1 does not need us to
> distinguish
> between O1 and O2.
>
> To summarize, a good approximation is indeed possible at compile time.
>
>
>> the aliasing&  pointer equivalence issues (a task known to be
>> impossible). How can the compiler surely know that pointer p in [a
>> particular instruction of] method YourClass::foo() is never (or
>> sometimes, or always) pointing to the same instance -in the running
>> process of the compiled program- as pointer q in method yourclass::bar()
>
> Basile, you keep mentioning that English is not your first language and I
> appreciate your politeness for reminding the reader for that (English is not
> the first language for me too). It is in that light that I would like to
> point
> out that your use of word "impossible" is a little too strong. Perhaps you
> mean
> difficult. It is impossible if you want exact information. However, if
> imprecisions can be tolerated for some gains, excellent approximations are
> possible _within_ a procedure body which is what Jeff asked for, to begin
> with.
>
> We have been working on this problem (pointer analysis) for a while but
> are quite far from production implementation. Our ideas now seem to mature
> a bit and whenever we have a conference paper, I will be happy to share it
> with the gcc folks.
>
>> Or maybe you want to instrument your compiler so that for every code
>> emitted for method yourclass::gee() you add a first block which checks
>> that the this reciever is not a given pointer.
>>
>> In other words&  C++ parlance, you could (this is doable, but not
>> trivial) hack the compiler so that at the start of every method (i.e.
>> member function in C++) the equivalent of the following C++ code has
>> been magically added
>>
>>   extern "C" YourClass* hunted_yourclass_pointer;
>>   extern "C" void some_error_routine(void);
>>
>>   if (this == hunted_yourclass_pointer)
>>     some_error_routine();
>
> This is a very good way of paraphrasing the "ideal" requirement.
>
> Regards,
>
> Uday.
>

Re: Guidance needed: hi-level steps to track an object until its destruction

[Uday P. Khedker]

Unfortunately I am not aware of C# implementation so can't respond to this...

Uday.

J Decker wrote, On Sunday 29 August 2010 05:32 PM:
> Just out of curiosity - isn't this what C# does with objects?  would
> it perhaps be something like that in how mcs (mono) builds objects and
> tracks their lifespan?
>
> On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker<uday@cse.iitb.ac.in>  wrote:
>>
>>> I am not sure that is easily feasible. I would believe it is impossible.
>>>
>>> Within the compiler (or inside a GCC plugin, or inside a GCC extension
>>> coded in MELT), you probably are able change/inspect C++ classes&    every
>>> other declaration any compiler is tracking. You are also able to find
>>> every occurrence of variables containing a pointer to such classes.
>>
>>>
>>> However, you are apparently willing to track a single *instance* of such
>>> a class, and this instance is in the execution of the compiled program
>>> [not inside the compiler]. This means that you are able to deal with all
>>
>>
>> To put it in other words: Here the issue is seeking runtime information at
>> compile time. An object is a run time entity. At compile time, we only see
>> the class. However, we also see the statements that create an object and
>> manipulate it. Although it is not possible to track each object distinctly,
>> a compile time approximation is certainly possible. And that is where
>> creativity
>> in compiler research lies. The better the approximations, the better the
>> gains.
>> For example, all objects that get created by a given statement can be
>> treated
>> alike. There is no way of distinguishing between them at compile time, but
>> perhaps
>> there is no need to do so because all of them are likely to be treated alike
>> at run time. if an object O1 and O2 are created by the same statement,
>> asking
>> the question whether a method m1 is invoked for O1 does not need us to
>> distinguish
>> between O1 and O2.
>>
>> To summarize, a good approximation is indeed possible at compile time.
>>
>>
>>> the aliasing&    pointer equivalence issues (a task known to be
>>> impossible). How can the compiler surely know that pointer p in [a
>>> particular instruction of] method YourClass::foo() is never (or
>>> sometimes, or always) pointing to the same instance -in the running
>>> process of the compiled program- as pointer q in method yourclass::bar()
>>
>> Basile, you keep mentioning that English is not your first language and I
>> appreciate your politeness for reminding the reader for that (English is not
>> the first language for me too). It is in that light that I would like to
>> point
>> out that your use of word "impossible" is a little too strong. Perhaps you
>> mean
>> difficult. It is impossible if you want exact information. However, if
>> imprecisions can be tolerated for some gains, excellent approximations are
>> possible _within_ a procedure body which is what Jeff asked for, to begin
>> with.
>>
>> We have been working on this problem (pointer analysis) for a while but
>> are quite far from production implementation. Our ideas now seem to mature
>> a bit and whenever we have a conference paper, I will be happy to share it
>> with the gcc folks.
>>
>>> Or maybe you want to instrument your compiler so that for every code
>>> emitted for method yourclass::gee() you add a first block which checks
>>> that the this reciever is not a given pointer.
>>>
>>> In other words&    C++ parlance, you could (this is doable, but not
>>> trivial) hack the compiler so that at the start of every method (i.e.
>>> member function in C++) the equivalent of the following C++ code has
>>> been magically added
>>>
>>>    extern "C" YourClass* hunted_yourclass_pointer;
>>>    extern "C" void some_error_routine(void);
>>>
>>>    if (this == hunted_yourclass_pointer)
>>>      some_error_routine();
>>
>> This is a very good way of paraphrasing the "ideal" requirement.
>>
>> Regards,
>>
>> Uday.
>>

Re: Guidance needed: hi-level steps to track an object until its destruction

[Basile Starynkevitch]

On Sun, 2010-08-29 at 17:13 +0530, Uday P. Khedker wrote:
> > I am not sure that is easily feasible. I would believe it is impossible.
> >
> > Within the compiler (or inside a GCC plugin, or inside a GCC extension
> > coded in MELT), you probably are able change/inspect C++ classes&  every
> > other declaration any compiler is tracking. You are also able to find
> > every occurrence of variables containing a pointer to such classes.
> 
> >
> > However, you are apparently willing to track a single *instance* of such
> > a class, and this instance is in the execution of the compiled program
> > [not inside the compiler]. This means that you are able to deal with all
> 
> 
> To put it in other words: Here the issue is seeking runtime information at
> compile time. An object is a run time entity. At compile time, we only see
> the class. However, we also see the statements that create an object and
> manipulate it. Although it is not possible to track each object distinctly,
> a compile time approximation is certainly possible. And that is where creativity
> in compiler research lies. The better the approximations, the better the gains.
> For example, all objects that get created by a given statement can be treated
> alike. There is no way of distinguishing between them at compile time, but perhaps
> there is no need to do so because all of them are likely to be treated alike
> at run time. if an object O1 and O2 are created by the same statement, asking
> the question whether a method m1 is invoked for O1 does not need us to distinguish
> between O1 and O2.
> 
> To summarize, a good approximation is indeed possible at compile time.
> 
> 
> > the aliasing&  pointer equivalence issues (a task known to be
> > impossible). How can the compiler surely know that pointer p in [a
> > particular instruction of] method YourClass::foo() is never (or
> > sometimes, or always) pointing to the same instance -in the running
> > process of the compiled program- as pointer q in method yourclass::bar()
> 
> Basile, you keep mentioning that English is not your first language and I
> appreciate your politeness for reminding the reader for that (English is not
> the first language for me too). It is in that light that I would like to point
> out that your use of word "impossible" is a little too strong. Perhaps you mean
> difficult. It is impossible if you want exact information. 

Yes, that is what I meant. Any compile-time tool produces some
abstraction.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***