GIMPLE Question

GIMPLE Question

[Kyle Girard]

I have the following code:

foo.hh
======

class A
{
};

class foo
{
  A a;
public:
    void bar(A & aa);
};


foo.cc
======

#include "foo.hh"

void foo::bar(A & aa)
{
  a = aa;
}


However the gimple generated via g++-4.5 -c -fdump-tree-gimple foo.cc 

is this:

void foo::bar(A&) (struct foo * const this, struct A & aa)
{
  GIMPLE_NOP
}


My question is this, what do I have to do to get the contents of the bar
method?  I am working on a plugin that traverses the AST and GIMPLE but
I cannot seem to get the contents of methods similar to this example...
all I get is a GIMPLE_NOP.  When the method is a little more complex I
get the proper gimple and all is well .... but simple methods elude me. 

Is there gimple for such a simple method or do I have to delve into the
some other part of the AST in order to get the information I need?  Any
hints as to how I would go about doing that?

Cheers,

Kyle

Re: GIMPLE Question

[Dave Korn]

On 25/02/2011 15:20, Kyle Girard wrote:

> foo.hh
> ======
> 
> class A
> {
> };
> 
> class foo
> {
>   A a;
> public:
>     void bar(A & aa);
> };
> 
> 
> foo.cc
> ======
> 
> #include "foo.hh"
> 
> void foo::bar(A & aa)
> {
>   a = aa;
> }
> 
> 
> However the gimple generated via g++-4.5 -c -fdump-tree-gimple foo.cc 
> 
> is this:
> 
> void foo::bar(A&) (struct foo * const this, struct A & aa)
> {
>   GIMPLE_NOP
> }
> 
> 
> My question is this, what do I have to do to get the contents of the bar
> method?

  That *is* the content of the bar method.  What exactly do you expect to see
happening when you assign a class with no members?  There's nothing to do!


    cheers,
      DaveK

Re: GIMPLE Question

[Kyle Girard]

>   That *is* the content of the bar method.  What exactly do you expect to see
> happening when you assign a class with no members?  There's nothing to do!


I was hoping to see the assignment.  My example might have been a little
too simple.  Here's a slightly more complex example:

foo.hh

class A
{
public:
   void yay(){};
};

class foo
{
  A a;
public:
    void bar(A & aa);
    void wik();
};


foo.cc


#include "foo.hh"

void foo::bar(A & aa)
{
  a = aa;
}

void foo::wik()
{
  a.yay();
}


foo.cc.004t.gimple


void foo::wik() (struct foo * const this)
{
  struct A * D.1731;

  D.1731 = &this->a;
  A::yay (D.1731);
}


void A::yay() (struct A * const this)
{
  GIMPLE_NOP
}


void foo::bar(A&) (struct foo * const this, struct A & aa)
{
  GIMPLE_NOP
}


Looking at the gimple output there is no way to see that 'a' was
assigned in bar().  So that it can be used in wik().  Am I
misunderstanding something shouldn't there be a way to see the
assignment in bar?  Do I have to parse the expression statement or are
things already optimized away and there is no way to get the information
that I seek.


Cheers,

Kyle

Re: GIMPLE Question

[Andrew Pinski]

On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard <kyle@kdmanalytics.com> wrote:
>
>>   That *is* the content of the bar method.  What exactly do you expect to see
>> happening when you assign a class with no members?  There's nothing to do!
>
>
> I was hoping to see the assignment.  My example might have been a little
> too simple.  Here's a slightly more complex example:
>
> foo.hh
>
> class A
> {
> public:
>   void yay(){};
> };

A is still an empty class, try adding "int a;" and you will see some code there.

Thanks,
Andrew Pinski

Re: GIMPLE Question

[Dave Korn]

On 25/02/2011 19:21, Kyle Girard wrote:

> I was hoping to see the assignment.

> Looking at the gimple output there is no way to see that 'a' was
> assigned in bar().  So that it can be used in wik().  Am I
> misunderstanding something shouldn't there be a way to see the
> assignment in bar?  Do I have to parse the expression statement or are
> things already optimized away and there is no way to get the information
> that I seek.

  Ah, right.  Yes, the stuff you see at the GIMPLE level has already been
substantially processed compared to the original AST - operations decomposed,
constants folded, that kind of thing.  For instance if (like Andrew suggests)
we add a "int x;" declaration in class A from your original example, we get:

> void foo::bar(A&) (struct foo * const this, struct A & aa)
> {
>   this->a = MEM[(const struct A &)aa];
> }

  You probably need to look earlier than GIMPLE time.  What plugin event are
you hooking?

    cheers,
      DaveK

Re: GIMPLE Question

[Joe Buck]

On Fri, Feb 25, 2011 at 11:33:58AM -0800, Andrew Pinski wrote:
> On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard <kyle@kdmanalytics.com> wrote:
> >
> >>   That *is* the content of the bar method.  What exactly do you expect to see
> >> happening when you assign a class with no members?  There's nothing to do!
> >
> >
> > I was hoping to see the assignment.  My example might have been a little
> > too simple.  Here's a slightly more complex example:
> >
> > foo.hh
> >
> > class A
> > {
> > public:
> >   void yay(){};
> > };
> 
> A is still an empty class, try adding "int a;" and you will see some code there.

The fact that passing an empty class has zero cost is used quite a bit in
the design of the standard library to generate efficient specialized
templates.  The empty objects are just used to select the correct
overloaded form.

Re: GIMPLE Question

[Kyle Girard]

On Fri, 2011-02-25 at 19:57 +0000, Dave Korn wrote:
> On 25/02/2011 19:21, Kyle Girard wrote:
> 
> > I was hoping to see the assignment.
> 
> > Looking at the gimple output there is no way to see that 'a' was
> > assigned in bar().  So that it can be used in wik().  Am I
> > misunderstanding something shouldn't there be a way to see the
> > assignment in bar?  Do I have to parse the expression statement or are
> > things already optimized away and there is no way to get the information
> > that I seek.
> 
>   Ah, right.  Yes, the stuff you see at the GIMPLE level has already been
> substantially processed compared to the original AST - operations decomposed,
> constants folded, that kind of thing.  For instance if (like Andrew suggests)
> we add a "int x;" declaration in class A from your original example, we get:
> 
> > void foo::bar(A&) (struct foo * const this, struct A & aa)
> > {
> >   this->a = MEM[(const struct A &)aa];
> > }
> 

Ok that's starting to make a little bit more sense...


>   You probably need to look earlier than GIMPLE time.  What plugin event are
> you hooking?


Currently, I try to get the earliest GIMPLE possible by using creating
my own pass like this

  struct register_pass_info pass_info;
  pass_info.pass = &myPass;
  pass_info.reference_pass_name = all_lowering_passes->name;
  pass_info.ref_pass_instance_number = 0;
  pass_info.pos_op = PASS_POS_INSERT_AFTER;
  register_callback(pluginName, PLUGIN_PASS_MANAGER_SETUP, NULL,
&pass_info);

Which, if I understand correctly gets me in before any major
optimization happens to the GIMPLE.  But by the sounds of it I will need
to go earlier somehow for some methods/functions.  Is it possible to be
an earlier pass and still have proper GIMPLE?

or can i hook in earlier and sort of put my own artificial GIMPLE in
somehow?  If that is possible how would I know when the to fake the
GIMPLE and when not to?

Cheers,

Kyle

Re: gimple question

[Joseph S. Myers]

On Mon, 12 Jul 2004, Razya Ladelsky wrote:

> Hello,
> 
> For the following function :
> 
> int foo (int i, int array[i++])
> {
>     return i;
> }
> 
> I can't find the explicit increment of i (appearing in the second 
> parameter) in the gimple tree.
> This information is preserved somewhere, as after rtl expansion, it 
> appears 
> explicitly in the body of the method.
> 
> Could someone point me where to look for this info?

Try the pending_sizes list.  That this works at all must be somewhat by
chance, as we certainly don't claim to implement C99 VLAs.  (My reading of
the standard is that this increment *is* required to be executed, as a
type being variably modified is a property of the declarator so while the
type of array is "int *" it still counts as variably modified so the size
expression must be executed on entry to the function.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: gimple question

[Jan Hubicka]

> > Geez, this is valid C?!  What is it _supposed_ to return?
> 
> This pattern appears in the gcc testsuite, in 
> gcc.c-torture/execute/970217-1.c 
> so I guess it is valid.
> It is supposed to return the value of i after it's been 
> incremented. 
Weird testcase ;)
I think it will be marked as has_hidden_use of the gimple register and
the increment will likely be in the PARM_DECL.  I think however that it
is gimplifier bug to not convert this into sane representation of the
semantics.

Honza
> 
> Razya
> 

Re: gimple question

[Razya Ladelsky]

> Geez, this is valid C?!  What is it _supposed_ to return?

This pattern appears in the gcc testsuite, in 
gcc.c-torture/execute/970217-1.c 
so I guess it is valid.
It is supposed to return the value of i after it's been 
incremented. 

Razya

Re: gimple question

[Steven Bosscher]

On Monday 12 July 2004 13:45, Razya Ladelsky wrote:
> Hello,
>
> For the following function :
>
> int foo (int i, int array[i++])
> {
>     return i;
> }

Geez, this is valid C?!  What is it _supposed_ to return?

> Could someone point me where to look for this info?

No idea.

Gr.
Steven

gimple question

[Razya Ladelsky]

Hello,

For the following function :

int foo (int i, int array[i++])
{
    return i;
}

I can't find the explicit increment of i (appearing in the second 
parameter) in the gimple tree.
This information is preserved somewhere, as after rtl expansion, it 
appears 
explicitly in the body of the method.

Could someone point me where to look for this info?

Thanks,
Razya