Re: Compilation of object creation in C++
On 2015-08-21 16:16, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker
wrote:
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
wrote:
Why is this different? Why is __comp_ctor not invoked in each
case?
This looks like the function has been inlined as it is short.
Thanks, this is a useful lead. Setting -fno-inline seems to do the
trick and
now the behaviour is same. C intermediate language
On 08/19/2015 06:00 PM, Richard Biener wrote:
On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker
wrote:
Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
Most of this is already in GCC 5 and above. Including the IPA
pass.
Have you looked into that pass yet?
From what I have read, it involves flow insensitive analysis
whereas we
are
looking at flow sensitive analysis.
It also performs flow-sensitive analysis, exactly like you suggest
by
looking
for constructor calls or patterns that involve setting the vtable
pointer
exposed through inlining.
When I said flow sensitive, I have interprocedural version in mind.
When I
looked up ipa-devirt.c,
there seems to be a traversal using FOR_EACH_DEFINED_FUNCTION (n),
but
nothing in it
indicates, an interprocedural transfer of information. I also looked
up Jan
Hubicka's blogs
(http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html)
and if I have understood it correctly, the analysis done by constant
propagation and global
value numbering is at the intraprocedural level (haven't looked up
these
passes though).
Here's a rather trivial example where gcc-5.1 misses
devirtualization
class A
{
public:
virtual void f() {cout << "\tA:f" << endl;}
};
class B : public A
{ public:
void f() {cout << "\tB:f" << endl;}
};
class C : public B
{
public:
void f() {cout<< "\tC:f" << endl;}
};
void fun1 (A *a, int i)
{
cout << "\nhi in fun1" << i << endl ;
a->f();
}
int main()
{
A *a1;
a1 = new A;
fun1 (a1, 10);
A *a2;
a2 = new A;
fun1 (a2, 5);
}
Assuming that there is no other translation unit and this is the
complete
program, the call a->f() is always for class
A but the dump in .058i.devirt says
Procesing function void fun1(A*, int)/232
Targets of polymorphic call of type 28:struct A token 0
Outer type (dynamic):struct A (or a derived type) offset 0
This is partial list; extra targets may be defined in other
units.
(derived types included)
virtual void A::f()/229 virtual void B::f()/230 virtual void
C::f()/231
suggesting that A, B, and C are possible classes.
Even a simple field and context insensitive interprocedural analysis
would
figure out that only one call is
possible (assuming this is the complete program).
Did you tell GCC this is a complete program?
Yes, we did specify the -fwhole-program option with optimization level
O3.
Is there any other option we should try?
The situation we are looking at involves interprocedural propagation
with
complex calls such as a->f->g->h(). We
plan to use a demand driven flow, context, and field sensitive
sensitive
points-to analysis which involves just about enough
computation required to resolves such calls.
I see.
Richard.
Uday.
Unable to access fields of a record type in some cases
Hello, We want to fetch fields of a record type from the formal arguments of a function. For a RECORD_TYPE, we fetch the fields using TYPE_FIELDS. In the program 471.omnetpp (from the SPEC CPU2006 benchmark suite), we encountered a case where we were not able to access the fields. Below is the dump of the same record type showing different output in different functions. We are not able to access fields of the record type for the first case. Can you tell us the reason for different type nodes? Also can you suggest an approach to solve our problem. --- Pointer declared as "struct cMessage *" is a parameter in one function. Below is the dump of node "struct cMessage *". align 8 symtab 0 alias set -1 canonical type 0x2b8faa800690 context pointer_to_this chain 0x2b8fad7b3730 cMessage>> unsigned DI size bitsizetype> constant 64> unit size 0x2b8faa6d2000 sizetype> constant 8> align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 pointer_to_this > Another pointer also declared as "struct cMessage *" is a parameter in second function. Below is the dump of node "struct cMessage *". type needs-constructing BLK size unit size align 64 symtab 0 alias set -1 canonical type 0x2b8faa834c78 fields 0x2b8faa819150 cObject> ignored BLK file omnet_include/cmessage.h line 84 col 15 size unit size align 64 offset_align 128 offset bit offset context chain swati_test>> context pointer_to_this reference_to_this chain cMessage>> public unsigned DI size bitsizetype> constant 64> unit size 0x2b8faa6d2000 sizetype> constant 8> align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 pointer_to_this > --- Thank you. Regards, Swati
Re: Unable to access fields of a record type in some cases
On 2016-09-19 21:04, David Malcolm wrote: On Mon, 2016-09-19 at 10:09 +0200, Richard Biener wrote: On Mon, Sep 19, 2016 at 3:52 AM, Swati Rathi < swatira...@cse.iitb.ac.in> wrote: > Hello, > > We want to fetch fields of a record type from the formal arguments > of a > function. > For a RECORD_TYPE, we fetch the fields using TYPE_FIELDS. > > In the program 471.omnetpp (from the SPEC CPU2006 benchmark suite), > we > encountered a case where we were not able to access the fields. > Below is the > dump of the same record type showing different output in different > functions. We are not able to access fields of the record type for > the first > case. > > Can you tell us the reason for different type nodes? The first is a pointer to an incomplete struct like what you'd get from struct Foo *p; without a definition of struct Foo. > Also can you suggest an approach to solve our problem. Sorry, no. Are you running this from a gcc plugin? Yes. My pass is SIMPLE_IPA_PASS and is hooked after the "pta" pass. I am doing whole program analysis using -flto -flto-partition=none option. If so, maybe your code is running too early, before the record type is fully parsed? If that's the case, you could try running your code late r. Presumably you're hooking in to a callback, or registering a new pass relative to a pre-existing one. You could try hooking onto a different callback, or running the pass later. Hope this is helpful Dave Richard. > --- > > Pointer declared as "struct cMessage *" is a parameter in one > function. > Below is the dump of node "struct cMessage *". > > type > align 8 symtab 0 alias set -1 canonical type 0x2b8faa800690 > context > > pointer_to_this chain > 0x2b8fad7b3730 cMessage>> > unsigned DI > size 0x2b8faa6d20a8 > bitsizetype> constant 64> > unit size 0x2b8faa6d2000 > sizetype> constant 8> > align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 > pointer_to_this > > > > Another pointer also declared as "struct cMessage *" is a parameter > in > second function. Below is the dump of node "struct cMessage *". > > type -constructing > BLK > size > unit size > align 64 symtab 0 alias set -1 canonical type > 0x2b8faa834c78 > fields 0x2b8faa819150 cObject> > ignored BLK file omnet_include/cmessage.h line 84 col > 15 > size > unit size > align 64 offset_align 128 > offset > bit offset > context > chain 0x2b8faa8268e8 > swati_test>> context > pointer_to_this > reference_to_this > chain cMessage>> > public unsigned DI > size 0x2b8faa6d20a8 > bitsizetype> constant 64> > unit size 0x2b8faa6d2000 > sizetype> constant 8> > align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 > pointer_to_this > > > --- > > > Thank you. > > Regards, > Swati
How to access points-to information for function pointers
Hello,
I am trying to print points-to information for SSA variables as below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
How can I access this information?
Regards,
Swati
Re: How to access points-to information for function pointers
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA names?
What is the reason that it is not preserved for function pointers?
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
How can I access this information?
Regards,
Swati
Re: How to access points-to information for function pointers
On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
On April 26, 2014 12:31:34 PM CEST, Swati Rathi
wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as
below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
Thanks a lot. :) This is of great help.
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
The bitmap is set by identifying the bit using DECL_PT_UID.
For variables, referenced_var_lookup returns the associated variable.
For FUNCTION_DECL's, all we need to do is store a mapping between uid
and FUNCTION_DECL.
Is this correct?
Richard.
What is the reason that it is not preserved for function pointers?
Nobody uses this information.
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
You can of course recompute it when needed.
Richard.
How can I access this information?
Regards,
Swati
Re: How to access points-to information for function pointers
In some cases, GCC's pta pass does not dump the points-to information for
function pointers which are formal parameters.
Why is it so?
Also it does not store the information for the corresponding SSA name.
However, it dumps pointer information for the parameter variable as
.constprop.0.arg0 = { val1 val2 }
This is the value which should have been stored with the formal parameter.
Is there any way of accessing this value?
Also what is this new variable .constprop.0.arg0 which is
getting created?
It is not a local variable. How do we then access its value?
On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi wrote:
On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
On April 26, 2014 12:31:34 PM CEST, Swati Rathi
wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as
below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
Thanks a lot. :) This is of great help.
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
The bitmap is set by identifying the bit using DECL_PT_UID.
For variables, referenced_var_lookup returns the associated variable.
Note that this table is gone from recent GCC.
For FUNCTION_DECL's, all we need to do is store a mapping between uid and
FUNCTION_DECL.
Is this correct?
Correct.
Richard.
Richard.
What is the reason that it is not preserved for function pointers?
Nobody uses this information.
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
You can of course recompute it when needed.
Richard.
How can I access this information?
Regards,
Swati
Re: How to access points-to information for function pointers
On Monday 05 May 2014 04:37 PM, Richard Biener wrote:
On Mon, May 5, 2014 at 11:38 AM, Swati Rathi wrote:
In some cases, GCC's pta pass does not dump the points-to information for
function pointers which are formal parameters.
Why is it so?
Depends on the case.
Also it does not store the information for the corresponding SSA name.
However, it dumps pointer information for the parameter variable as
.constprop.0.arg0 = { val1 val2 }
This is the value which should have been stored with the formal parameter.
Is there any way of accessing this value?
Also what is this new variable .constprop.0.arg0 which is
getting created?
It is not a local variable. How do we then access its value?
It is the internal representation variable used in the points-to solving
algorithm. You can't access that outside of the pass.
Do you have a (simple) testcase that shows the issue?
Here is a testcase :
---
__attribute__ ((noinline)) void fun3(void (*fp) ())
{
fp();
}
void fun1()
{
printf("\nin fun1\n");
}
int main()
{
fun3(fun1);
}
---
Points-to information of formal argument fp is not dumped.
However, the value for fun3.arg0 = { fun1 } is being dumped.
Richard.
On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi
wrote:
On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
On April 26, 2014 12:31:34 PM CEST, Swati Rathi
wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as
below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
Thanks a lot. :) This is of great help.
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
The bitmap is set by identifying the bit using DECL_PT_UID.
For variables, referenced_var_lookup returns the associated variable.
Note that this table is gone from recent GCC.
For FUNCTION_DECL's, all we need to do is store a mapping between uid and
FUNCTION_DECL.
Is this correct?
Correct.
Richard.
Richard.
What is the reason that it is not preserved for function pointers?
Nobody uses this information.
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
You can of course recompute it when needed.
Richard.
How can I access this information?
Regards,
Swati
How to identify object of a class defined in library file
How to identify object of a class which is defined in the library file? For e.g. struct basic_ostream & D.2782; Variable D.2782 is object of class which is part of the library file. How can we identify such a variable? Regards, Swati
Re: How to identify object of a class defined in library file
I am referring to C++ standard library files. Statement : cout << "\tB:f" << endl; is translated as : struct basic_ostream & D.2782; struct basic_ostream & D.2781; : D.2782_1 = operator<< (&cout, "\tB:f"); D.2781_2 = D.2782_1; operator<< (D.2781_2, endl); I want to ignore variables D.2782 and D.2781 as they are object of class defined in standard library file. On Monday 08 September 2014 05:12 PM, Jonathan Wakely wrote: On 8 September 2014 11:53, Swati Rathi wrote: How to identify object of a class which is defined in the library file? For e.g. struct basic_ostream & D.2782; Variable D.2782 is object of class which is part of the library file. How can we identify such a variable? Repeating the question three times doesn't make it any clearer, what exactly are you asking? What are you referring to as "the library file"? libstdc++.so? Or some library of your own? Please give more context for your question.
How to access the virtual table?
I am trying to access the virtual table. My pass is hooked after pass_ipa_pta. Consider Class A which contains virtual function. An object created as : A a; is translated in GIMPLE as struct A a; From variable "a" we can get its type which is "struct A". I tried to see how the dump_vtable function access the table. To access the virtual table for class A, Below is the code which I tried. tree t = TREE_TYPE (a); tree binfo = TYPE_BINFO (t); tree vtab = BINFO_VTABLE (binfo); FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (DECL_INITIAL (vtab)), ix, value) Using the above iterator, entries of the virtual table should be accessible. However, I am not able to do so. Kindly inform me the way to access the virtual table. Also how to fetch the functions from that virtual table? Regards, Swati
Re: How to access the virtual table?
On Friday 12 September 2014 12:14 PM, Jan Hubicka wrote: I am trying to access the virtual table. My pass is hooked after pass_ipa_pta. Consider Class A which contains virtual function. An object created as : A a; is translated in GIMPLE as struct A a; From variable "a" we can get its type which is "struct A". I tried to see how the dump_vtable function access the table. To access the virtual table for class A, Below is the code which I tried. tree t = TREE_TYPE (a); tree binfo = TYPE_BINFO (t); tree vtab = BINFO_VTABLE (binfo); FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (DECL_INITIAL (vtab)), ix, value) Using the above iterator, entries of the virtual table should be accessible. However, I am not able to do so. You can check dump_tree (vtab) to see if you are seeing an VAR_DECL. BINFO_VTABLE is usually POINTER_PLUS_EXPR, so you want to access DECL_INITIAL of TREE_OPERAND (vtab) in that case. If you want to access an virtual method with given token (position in vtable), you can just use gimple_get_virt_method_for_binfo (or borrow code from there for things you need). Thanks a lot. This helped. Honza Kindly inform me the way to access the virtual table. Also how to fetch the functions from that virtual table? Regards, Swati
How to access the function body of a constructor?
I am trying to access the body of a constructor.
My pass is hooked after pass_ipa_pta.
Constructor for a class is invoked as :
__comp_ctor (&b);
However the constructor body is dumped as
__base_ctor (struct B * const this)
{
:
}
I am not able to access basic blocks from __comp_ctor?
Is __comp_ctor a cloned function of __base_ctor?
Also assuming it to be a cloned function, I tried to access it using
"clones", "clones_of" fields of structure cgraph_node.
But these fields does not store anything (or at least for the functions
I tried).
What does these fields (clones, clone_of etc.) store?
Will the macro DECL_CLONED_FUNCTION give me __base_ctor from __comp_ctor ?
I tried using it but it gives an error, "undefined symbol:
_Z22decl_cloned_function_pPK9tree_nodeb".
Kindly tell me way to access the constructor body.
Regards,
Swati
How to identify the type of the object being created using the new operator?
Hello, Statement : A *a = new B; gets translated in GIMPLE as 1. void * D.2805; 2. struct A * a; 3. D.2805 = operator new (20); 4. a = D.2805; A is the base class and B is the derived class. In statement 3, new operator is creating an object of derived class B. By analyzing the RHS of the assignment statement 3, how can we identify the type (in this case B) of the object being created? Regards, Swati
Re: How to identify the type of the object being created using the new operator?
On Monday 06 October 2014 02:28 PM, Marc Glisse wrote: On Mon, 6 Oct 2014, Swati Rathi wrote: Statement : A *a = new B; gets translated in GIMPLE as 1. void * D.2805; 2. struct A * a; 3. D.2805 = operator new (20); 4. a = D.2805; A is the base class and B is the derived class. In statement 3, new operator is creating an object of derived class B. By analyzing the RHS of the assignment statement 3, how can we identify the type (in this case B) of the object being created? I strongly doubt you can. It is calling B's constructor that will turn this memory region into a B, operator new is the same as malloc, it only returns raw memory. (If A and B don't have the same size, the argument 20 can be a hint) Argument 20 is the size of class B. This was obtained only if we knew that object B is created here. Is this information not stored anywhere else?
Re: How to access the function body of a constructor?
This post is in continuation to my below post.
My pass is hooked after pass_ipa_pta as already mentioned below.
I have enabled the LTO framework by using the flags "-flto
-flto-partition=none".
Without the LTO mode, macro DECL_CLONED_FUNCTION returns the cloned
constructor.
However, in the LTO mode this information is not available.
How do I make this information available in the LTO framework?
Is there any other way to get the cloned copy of the constructor
"__base_ctor" from "__comp_ctor"?
Regards,
Swati
On Monday 15 September 2014 03:41 PM, Swati Rathi wrote:
I am trying to access the body of a constructor.
My pass is hooked after pass_ipa_pta.
Constructor for a class is invoked as :
__comp_ctor (&b);
However the constructor body is dumped as
__base_ctor (struct B * const this)
{
:
}
I am not able to access basic blocks from __comp_ctor?
Is __comp_ctor a cloned function of __base_ctor?
Also assuming it to be a cloned function, I tried to access it using
"clones", "clones_of" fields of structure cgraph_node.
But these fields does not store anything (or at least for the
functions I tried).
What does these fields (clones, clone_of etc.) store?
Will the macro DECL_CLONED_FUNCTION give me __base_ctor from
__comp_ctor ?
I tried using it but it gives an error, "undefined symbol:
_Z22decl_cloned_function_pPK9tree_nodeb".
Kindly tell me way to access the constructor body.
Regards,
Swati
How to extract types of variables and its uid?
We want to store all the types associated with the class objects or pointer to a class in a program. Consider two variables var1 and var2 declared in different functions as below. class IStream *var1; class IStream *var2; We are extracting its type as below : tree type1 = TREE_TYPE (TREE_TYPE (var1)); tree type2 = TREE_TYPE (TREE_TYPE (var2)); TREE_CODE (type1) and TREE_CODE (type2) is RECORD_TYPE. We wish to record the type struct IStream. However, when we print TYPE_UID (type1) and TYPE_UID (type2), it is different. TYPE_UID = 4326, tree_type : struct IStream TYPE_UID = 7421, tree_type : struct IStream Using TYPE_UID (TYPE_MAIN_VARIANT (type1)) and TYPE_UID (TYPE_MAIN_VARIANT (type2)) also gives the same result. We wish to avoid duplicate entries of the same type. How to extract types and uid? Regards, Swati
Re: How to extract types of variables and its uid?
The variables are declared as you have mentioned. IStream *var1; IStream *var2; Also, var1 and var2 are declared in different functions. On Thursday 09 April 2015 03:30 PM, Richard Biener wrote: On Thu, Apr 9, 2015 at 11:57 AM, Swati Rathi wrote: We want to store all the types associated with the class objects or pointer to a class in a program. Consider two variables var1 and var2 declared in different functions as below. class IStream *var1; class IStream *var2; We are extracting its type as below : tree type1 = TREE_TYPE (TREE_TYPE (var1)); tree type2 = TREE_TYPE (TREE_TYPE (var2)); TREE_CODE (type1) and TREE_CODE (type2) is RECORD_TYPE. We wish to record the type struct IStream. However, when we print TYPE_UID (type1) and TYPE_UID (type2), it is different. TYPE_UID = 4326, tree_type : struct IStream TYPE_UID = 7421, tree_type : struct IStream Using TYPE_UID (TYPE_MAIN_VARIANT (type1)) and TYPE_UID (TYPE_MAIN_VARIANT (type2)) also gives the same result. We wish to avoid duplicate entries of the same type. How to extract types and uid? Doesn't it work with class IStream; IStream *var1; IStream *var2; ? Regards, Swati
Re: How to extract types of variables and its uid?
I have enabled the LTO infrastructure using -flto -flto-partition=none. In the LTO infrastructure, when I try to print the TYPE_UID for the types of variable var1 and var2, its different (as mentioned in my first post). IStream *var1; IStream *var2; On Thursday 09 April 2015 08:21 PM, Andrew Pinski wrote: On Thu, Apr 9, 2015 at 10:40 PM, Swati Rathi wrote: Even I am getting same uid's on small programs. I tried declaring variables across files also. But I am unable to replicate the problem on small programs. I am testing on SPEC CPU2006 benchmark suite, program - 453.povray Below is the information which is getting dumped using -fdump-tree-gimple-uid IStream has different uid's -> 5363, 5364, 11467 and 11521. In a file the uid is same. Can you suggest other experiments to identify the reason? Yes UID are only the same compiling unit. If you want to do some analysis with types across units you should be using LTO infrastructure. Thanks, Andrew
Re: How to extract types of variables and its uid?
Even I am getting same uid's on small programs.
I tried declaring variables across files also.
But I am unable to replicate the problem on small programs.
I am testing on SPEC CPU2006 benchmark suite, program - 453.povray
Below is the information which is getting dumped using
-fdump-tree-gimple-uid
IStream has different uid's -> 5363, 5364, 11467 and 11521. In a file
the uid is same.
Can you suggest other experiments to identify the reason?
--
defaultplatformbase.cpp.004t.gimple: struct IStreamD.5363 * D.6034;
express.cpp.004t.gimple: struct IStreamD.5363 * fD.16342;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6193;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6197;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6199;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6215;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6217;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6219;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * tD.6075;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 * D.6221;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 & D.6273;
fileinputoutput.cpp.004t.gimple: struct IStreamD.5364 & D.6286;
iff.cpp.004t.gimple: struct IStreamD.5363 * fD.7934;
octree.cpp.004t.gimple: struct IStreamD.5364 & D.14872;
pattern.cpp.004t.gimple: struct IStreamD.5363 * fileD.17068;
pgm.cpp.004t.gimple: struct IStreamD.5363 * filepD.7964;
pov_util.cpp.004t.gimple: struct IStreamD.5363 * D.8057;
pov_util.cpp.004t.gimple: struct IStreamD.5363 * resultD.7911;
pov_util.cpp.004t.gimple: struct IStreamD.5363 * D.8065;
ppm.cpp.004t.gimple: struct IStreamD.5363 * filepD.8409;
ppm.cpp.004t.gimple: struct IStreamD.5363 * D.8683;
ppm.cpp.004t.gimple: struct IStreamD.5363 * D.8894;
ppm.cpp.004t.gimple: struct IStreamD.5363 * D.8940;
ppm.cpp.004t.gimple: struct IStreamD.5363 * D.8941;
radiosit.cpp.004t.gimple: struct IStreamD.11467 * fdD.14868;
targa.cpp.004t.gimple: struct IStreamD.5363 * filepD.8491;
targa.cpp.004t.gimple: struct IStreamD.5363 * D.8856;
targa.cpp.004t.gimple: struct IStreamD.5363 * D.9155;
targa.cpp.004t.gimple: struct IStreamD.5363 * D.9196;
targa.cpp.004t.gimple: struct IStreamD.5363 * D.9197;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12125;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12188;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12208;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12267;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12286;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12293;
textstream.cpp.004t.gimple: struct IStreamD.11521 * D.12294;
tokenize.cpp.004t.gimple: struct IStreamD.5363 * isD.10339;
tokenize.cpp.004t.gimple: struct IStreamD.5363 * isD.10040;
tokenize.cpp.004t.gimple: struct IStreamD.5363 * rfileD.10196;
tokenize.cpp.004t.gimple: struct IStreamD.5363 * isD.10167;
tokenize.cpp.004t.gimple: struct IStreamD.5363 * rfileD.9708;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9604;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9801;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9820;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9959;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9962;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.9969;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10101;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10177;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10182;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10216;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10221;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10249;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10343;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10405;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10421;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10524;
truetype.cpp.004t.gimple: struct IStreamD.5363 * D.10579;
--
On Thursday 09 April 2015 04:13 PM, Richard Biener wrote:
On Thu, Apr 9, 2015 at 12:41 PM, Swati Rathi wrote:
The variables are declared as you have mentioned.
IStream *var1;
IStream *var2;
Also, var1 and var2 are declared in different functions.
Works for me.
class IStream;
void foo (void) { IStream *var1; }
void bar (void) { IStream *var2; }
g++ -S t.C -fdump-tree-gimple-uid
cat t.C.004t.gimple
void foo() ()
{
struct IStreamD.2324 * var1D.2327;
}
void bar() ()
{
struct IStreamD.2324 * var2D.2330;
}
thus both TYPE_NAMEs have the same DECL_UID 2324.
Their type, even the pointer type have the same TYPE_UID as well
as seen in a debugging session looking at the functions BLOCK
tree before gimplification.
Yo
Re: How to extract types of variables and its uid?
On Friday 10 April 2015 01:00 PM, Richard Biener wrote: Or is there any other unique feature to distinguish between two tree types, >other than type uid? Depends on the definition of the equality relation. We have considered the file name and line number where the types are defined as a unique feature to distinguish between two tree types. Thanks a lot. :-) Regards, Swati
How to access structure information from "pass_vectorize"
We are writing a GIMPLE pass and would like to use some information computed in pass_vectorize. However, we are not able to use the data structures which gets populated in pass_vectorize because the information is not made available across passes. In particular, we wish to access the structures "stmt_vec_info" and "data_reference". How do we access this information? Should we invoke pass_vectorize as a sub-pass of our pass? Should we explicitly call the execute function of pass_vectorize in our pass? Or should we modify pass_vectorize code and make a deep copy in a global variable? Is there any other way of getting this information?
Re: How to access structure information from "pass_vectorize"
On Monday 20 January 2014 02:20 PM, Richard Biener wrote:
On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi wrote:
We are writing a GIMPLE pass and would like to use some information computed
in
pass_vectorize. However, we are not able to use the data structures which
gets populated in pass_vectorize
because the information is not made available across passes.
In particular, we wish to access the structures "stmt_vec_info" and
"data_reference".
How do we access this information? Should we invoke pass_vectorize as a
sub-pass of our pass? Should
we explicitly call the execute function of pass_vectorize in our pass? Or
should we modify pass_vectorize
code and make a deep copy in a global variable? Is there any other way of
getting this information?
It really depends on what kind of information you want to access. You can
re-compute things in your pass, or you can make your pass part of the
vectorizer (thus, modify the vectorizer pass). In particular data_reference
is just what the data-reference analysis usable from any pass (tree-data-ref.h)
produces.
But without more information on what information exactly you want to access
(and where - where is your pass placed compared to the vectorizer?) it is
hard to suggest anything.
Richard.
We wish to access the chain of recurrence (chrecs) which is being
populated in the below structure.
struct indices
{
/* The object. */
tree base_object;
/* A list of chrecs. Access functions of the indices. */
VEC(tree,heap) *access_fns;
/* Whether BASE_OBJECT is an access representing the whole object
or whether the access could not be constrained. */
bool unconstrained_base;
};
Our pass is placed after "pass_ipa_pta".
However, we even tried placing the pass after pass_vectorize to access
this information.
Can we use the chain of recurrence computed by the pass_vectorize or do
we have to recompute it?
Is there any other pass which is also computing this information and can
we access it?
