Re: Remove node from cgraph

2013-01-25 Thread Chassin 

On 01/24/2013 06:43 AM, Richard Biener wrote:

On Thu, Jan 24, 2013 at 4:46 AM, Chassin  wrote:

On 01/23/2013 02:37 PM, Richard Biener wrote:

Please keep this on the list.

On Wed, Jan 23, 2013 at 5:52 PM, Chassin 
wrote:

On 01/23/2013 10:55 AM, Richard Biener wrote:

The callgraph isn't the main data structure to modify here.  You probably
still
have references to the function in the IL via calls for example.  You
probably
want to remove all calls to the cgraph node.

Thanks for the quick replay Sr , do you mean by removing calls the (
edges )
? , but  by using cgraph_remove_node it seams to delete all callee and
callers to that node



01494   cgraph_node_remove_callers (node);
01495   cgraph_node_remove_callees (node);
01496   ipa_remove_all_references (&node->ref_list);
01497   ipa_remove_all_refering (&node->ref_list);
...


in the dump file in my previous mail it shows that all edges related were
removed , should i remove the reference in the GIMPLE body manually ? how
?

You need to remove the call stmts - they are the main representation
of the edges which
get re-built when needed.  You can iterate over the call statements
via the cgraph node
callers list of edges.  In the cgraph edge structure you'll find a
call_stmt member.  To
remove it you need to switch to the corresponding function (push/pop_cfun,
use
DECL_STRUCT_FUNCTION (edge->caller->decl)) and then remove the stmt via
for example gsi_remove () after initializing an iterator via gsi_for_stmt.

That's not all of the details, you of course have to think of what to
do for other
references to the function (function pointers and later indirect
calls).  You have to
think about what the point is of removing arbitrary calls throughout a
program
of course - I can't see any good reason to do this kind of stuff ;)

Richard.


cheers

--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty

48 Aniversario del Instituto Superior Politécnico José Antonio
Echeverría,
Cujae Una obra de la Revolución Cubana | 2 de diciembre de 1964 |
http://cujae.edu.cu


Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

Hi Ms.Richard , i am new to gcc , i got confused so by removing the edge i
am really not doing anything !!! cuz if the call stmt still exist , did i
understood right ?
if so then what really the edge represent ??

Callgraph nodes and callgraph edges are a representation of functions
and call statements.  The functions with their statements are the main
representation of the intermediate language ontop of which other
high-level data structures are built.  The functions and their statements
are the representation to change.


, can you provide me a sample
code how to do that ?

No, because it's quite a nonsensical operation so there doesn't exist
an example in GCC itself I can point you to.

Please do not continue to ask me questions privately, but post questions
on the mailing-list.  This way other people can benefit as well from your
questions and answers you get.

Richard.


thnx for your time


--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty



48 Aniversario del Instituto Superior Politecnico Jose Antonio Echeverria,
Cujae
Una obra de la Revolucion Cubana | 2 de diciembre de 1964 |
http://cujae.edu.cu




Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Richard thnx for your feedbacks i managed to code the function here i 
provide a sample ,


// This will remove just one call but i think with this we can get 
a start point to manage how to delete all other references

char *in_str="main";
char *to_str="f_1";
struct cgraph_node *in_node = util_get_cgnode_by_name(in_str);
struct cgraph_node *to_node = util_get_cgnode_by_name(to_str);
struct cgraph_edge *edge= 
util_get_cgedge_matches_first_call(in_node,to_node);


push_cfun(DECL_STRUCT_FUNCTION(in_node->decl));
int i=0;
basic_block bb;
gimple_stmt_iterator gsi;
gimple stmt;

// itearte over the basic block in the current function pushed
FOR_EACH_BB(bb)
for (gsi=gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi))
{
stmt = gsi_stmt(gsi);
if(stmt == edge->call_stmt)
{
gsi_remove((&gsi), true); // remove the stmt
}
}

cgraph_remove_edge(edge);


Sample  APP calls Before
main -> f_1
After
main

--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty



48 Aniversario del Instituto Superior Politecnico Jose Antonio Echeverria, Cujae
Una obra de la Revolucion Cubana | 2 de diciembre de 1964 | http://cujae.edu.cu



Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

Re: Question on lower-subreg.c

2013-01-25 Thread Bin.Cheng 
On Fri, Jan 25, 2013 at 3:57 PM, Bin.Cheng  wrote:
> Hi,
> I read code in lower-subreg.c and found GCC only split some of
> multi-word mode instructions, like load from memory into pseudo reg,
> etc. The related code is in find_decomposable_subregs.
>
> So for below example from PR56102:
>
> double g = 1.0;
> double func(int a, double d)
> {
> if (a > 0)
> return 0.0 + g;
> else
> return 2.0 + d;
> }
>
> compiling with:
> ./arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os test.c -S -o test.S
>
> If split is done for all DFmode insns, it will save us code size by
> sharing constant pool in program.
>
> My questions are:
> 1. Why don't split other multi-word insns?
> 2. Is it possible to do it in subreg2 pass, or in backend?
> I know little about lower-subreg.c, did I miss something important?
>
Sorry that I missed the point the subreg passes is only used to split
multi-word pseudo which appeared in SUBREG.

--
Best Regards.

Re: Bootstrapping glibc vs. dependency on system headers

2013-01-25 Thread Thomas Schwinge 
Hi!

On Wed, 23 Jan 2013 14:34:09 -0800, Roland McGrath  wrote:
> For libc, I think always using $CC -E is fine.  You don't need to bother
> with the MSG_CHECKING and CACHE_VAL boilerplate.

Ah, I thought the caching was required to have config.status' --recheck
do the right thing.  Which actually isn't.

> It's best if comments refer to a URL in a bug database (libc's bugzilla or
> another one, whatever) with details filed there rather than pointing to a
> mailing list thread.  If you do use URLs to mailing list archives, they
> must be to the canonical archive (http://sourceware.org/ml/libc-alpha/...)
> rather than to some third-party site.

Opening a bug for that issue seemed overkill to me.  What I don't like
about the sourceware archives is that they fail on non-ASCII characters
as well as indexing over month boundaries.

Pushed as commit bb931195fe780bb63e3d57d0742abad1d2128424:

* configure.in (AC_PROG_CPP): New definition.
* configure: Regenerate.

diff --git configure.in configure.in
index 4cfa36d..2c50d09 100644
--- configure.in
+++ configure.in
@@ -17,6 +17,23 @@ AC_DEFUN([_AC_INCLUDES_DEFAULT_REQUIREMENTS],
   [m4_divert_text([DEFAULTS],
 [ac_includes_default='/* none */'])])
 
+# We require GCC, and by default use its preprocessor.  Override AC_PROG_CPP
+# here to work around the Autoconf issue discussed in
+# .
+AC_DEFUN([AC_PROG_CPP],
+[AC_REQUIRE([AC_PROG_CC])dnl
+AC_ARG_VAR([CPP],  [C preprocessor])dnl
+_AC_ARG_VAR_CPPFLAGS()dnl
+# On Suns, sometimes $CPP names a directory.
+if test -n "$CPP" && test -d "$CPP"; then
+  CPP=
+fi
+if test -z "$CPP"; then
+  CPP="$CC -E"
+fi
+AC_SUBST(CPP)dnl
+])# AC_PROG_CPP
+
 dnl This is here so we can set $subdirs directly based on configure fragments.
 AC_CONFIG_SUBDIRS()
 


Grüße,
 Thomas


pgpRtIeYzV5FO.pgp
Description: PGP signature

Re: Bootstrapping glibc vs. dependency on system headers

2013-01-25 Thread Thomas Schwinge 
Hi!

On Fri, 18 Jan 2013 11:37:16 +0100, I wrote:
> On Thu, 17 Jan 2013 18:09:33 +0100, I wrote:
> > Also known as: »I found another one«.
> 
> (That's the last one I'm currently seeing.)  Again depending on
>  usability, we either get:
> 
> checking for [GCC] option to accept ISO C89... none needed
> 
> Or:
> 
> checking for [GCC] option to accept ISO C89... unsupported
> 
> As setting »ac_cv_prog_cc_c89=no« (which we never check for) is all what
> this test does, and we're C89 always by our compiler requirements, it is
> safe to simply elide it.  Tested on x86_64 GNU/Linux for a ARM GNU/Linux
> host.

As obvious, pushed as commit b5a5da237648077c98c10d359fe3b62b9e18f811:

* configure.in (_AC_PROG_CC_C89): New definition.
* configure: Regenerate.

diff --git configure.in configure.in
index 2c50d09..c578979 100644
--- configure.in
+++ configure.in
@@ -34,6 +34,11 @@ fi
 AC_SUBST(CPP)dnl
 ])# AC_PROG_CPP
 
+# We require GCC.  Override _AC_PROG_CC_C89 here to work around the Autoconf
+# issue discussed in
+# .
+AC_DEFUN([_AC_PROG_CC_C89], [[$1]])
+
 dnl This is here so we can set $subdirs directly based on configure fragments.
 AC_CONFIG_SUBDIRS()
 


Grüße,
 Thomas


pgpqx9KjhIzxs.pgp
Description: PGP signature

Re: gcc : c++11 : full support : eta?

2013-01-25 Thread Paolo Bonzini 
Il 25/01/2013 08:24, Uday P. Khedker ha scritto:
> Exactly. We have been using our training program since 2007 (and have
> been incrementally refining it on a continuously). Our experience has
> been that it has brought down the ramp up period of novices to a couple
> of week.

A couple of weeks is really unbelievable.  Congratulations!

Paolo

Re: mips16 and nomips16

2013-01-25 Thread Maciej W. Rozycki 
On Tue, 15 Jan 2013, David Daney wrote:

> > I'm not understanding why mips16 and nomips16 are not simple inheritable
> > attributes.
> 
> The mips16ness of a function must be known by the caller so that the
> appropriate version of the JAL/JALX instruction can be emitted

 Not really, the issue of JAL vs JALX is sorted out by the linker, for
both instruction encodings.

 It is the use of tail/sibling calls that is more of a problem (there's no
JX instruction to relax J to; of course this applies to standard MIPS code
only, as there's no MIPS16 J instruction), but that is generally
controlled with the -minterlink-mips16 option.

 The same applies to mixing standard MIPS and microMIPS code as far as the
linker is concerned (there are some additional restrictions due to a short
delay slot a jump instruction may have; such instructions cannot be
relaxed to cross-mode jumps).

> > i..e you should be able to say:
> > 
> > void foo();
> > void __attribute((nomips16)) foo();
> > 
> > 
> > or
> > 
> > void goo();
> 
> Any call here would assume nomips16
> 
> > void __attribute((mips16)) goo();
> 
> A call here would assume mips16.
> 
> Which is it?  If you allow it to change, one case will always be incorrect.

 You can still provide a prototype with neither attribute applied and then
build the actual function as either standard MIPS or MIPS16 code by using
the -mips16 or -mno-mips16 command line option.

  Maciej

Re: mips16 and nomips16

2013-01-25 Thread Maciej W. Rozycki 
On Fri, 18 Jan 2013, Richard Sandiford wrote:

> > I would assume that foo would be nomips16 and goo would be mips16.
> >
> > The definition of plain foo() or goo() says that nothing is specified.
> >
> > What is not clear then?
> >
> > This is how all such other attributes in gcc are handled.
> 
> Well, in a way, these are the only such attributes in GCC :-)
> I don't think any other port supports switching between different
> ISA modes like this.
> 
> I think the original authors really wanted "mips16" and "nomips16" to be
> type attributes rather than decl attributes.  nomips16 function pointers
> and mips16 function pointers would be mutually-incompatible subtypes of
> unannotated function pointers, so you would be able to implicitly
> convert an annotated function pointer to an unannotated one, but not the
> other way, and not between annotated function pointers.  GCC didn't at
> the time (and as far as I know still doesn't) have hooks to enforce that
> though.  The attributes therefore ended up being implemented as strict
> decl attributes in the hope that they could be made type attributes in
> future without breaking backwards compatibility.
> 
> Not having those hooks means that the validity and semantics of:
> 
>  void foo();
>  void __attribute((subtype)) foo();
> 
> aren't really defined.  Does foo() keep its original type or change to
> the subtype?  It's also not defined whether:
> 
>  void __attribute((subtype)) foo();
>  void foo();
> 
> is invalid, or whether the subtype from the first declaration carries
> over to the second.  Etc.  (To be clear, I'm not trying to start a
> discussion on the right semantics, or anything like that.  I'm just
> saying that I don't think the semantics are defined yet, although
> I could be wrong.)

 FWIW, I think the benefit from these attributes being a type property is 
questionable to say the least.  My understanding is the only application 
is to prevent the tail-call optimisation from being applied to non-PIC 
standard MIPS functions that otherwise would have to make a direct jump to 
MIPS16 code for which there is no hardware support (note that there is no 
issue with PIC code as with register jumps the ISA bit can be freely set 
at will as required).

 If that is the case, then perhaps producing a suitable call thunk 
instead, similar to these we use to pass floating-point arguments around 
with MIPS16 functions or to call PIC code from non-PIC code statically 
linked together, so that all standard MIPS code is link-time compatible 
with MIPS16 would be a better option?

  Maciej

Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2

2013-01-25 Thread Sudakshina Das 
On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
 wrote:
>
> On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
>  wrote:
> >
> > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
> >  wrote:
> > > Dear all,
> > >
> > > I am currently updating a pass that was made for gcc-4.6.*, so that it
> > > works for gcc.4.7.2.
> > >
> > > In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
> > > was picked up and used.
> > > Given below is the fragment taken form create_function_info_for () .
> > > This fragment was used to create variable information for the function
> > > and it was picked up to perform a similar operation in the added pass
> > > as well.
> > >
> > > But in gcc-4.7.2 some changes are introduced in the fragment. The code
> > > given below shows the changes that have been introduced in
> > > create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
> > > along with the original code in the comments.
> > >
> > >   /* Add one representative for all further args.  */
> > >   if (is_varargs)
> > > {
> > >   varinfo_t argvi;
> > >   const char *newname;
> > >   char *tempname;
> > >   tree decl;
> > >
> > >   asprintf (&tempname, "%s.varargs", name);
> > >   newname = ggc_strdup (tempname);
> > >   free (tempname);
> > >
> > >   /* We need sth that can be pointed to for va_start.  */
> > >
> > > / CHANGED CODE in GCC-4.7.2 ***/
> > >   decl = build_fake_var_decl (ptr_type_node);
> > >
> > > / ORIGINAL CODE in GCC-4.6.2 ***
> > > /*  decl = create_tmp_var_raw (ptr_type_node, name);
> > > get_var_ann (decl);
> > > */
> > >
> > >   argvi = new_var_info (decl, newname);
> > >   argvi->offset = fi_parm_base + num_args;
> > >   argvi->size = ~0;
> > >   argvi->is_full_var = true;
> > >   argvi->is_heap_var = true;
> > >   argvi->fullsize = vi->fullsize;
> > >   gcc_assert (prev_vi->offset < argvi->offset);
> > >   prev_vi->next = argvi;
> > >   prev_vi = argvi;
> > > }
> > >
> > >   return vi;
> > >
> > >
> > > So I made the same changes in the pass where this fragment was used.
> > > But after making the changes the pass is now giving an "internal
> > > compiler error" and a "segmentation fault" at runtime.
> > >
> > > After debugging I could narrow it down to the function
> > > build_fake_var_decl() and to be specific at the memory allocation
> > > statement highlighted below.
> > >
> > >
> > > tree
> > > build_fake_var_decl (tree type)
> > > {
> > > / My debugging showed that the control came
> > > here */
> > >   tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct 
> > > tree_var_decl);
> > > / But did not come here
> > > **/
> > >   memset (decl, 0, sizeof (struct tree_var_decl));
> > >   TREE_SET_CODE (decl, VAR_DECL);
> > >   TREE_TYPE (decl) = type;
> > >   DECL_UID (decl) = allocate_decl_uid ();
> > >   SET_DECL_PT_UID (decl, -1);
> > >   layout_decl (decl, 0);
> > >   return decl;
> > > }
> > >
> > > The builf_fake_var_decl() function is a gcc function defined in
> > > tree-ssa-structalias.c. To be able to use it in my pass, I removed the
> > > keyword static in its definition.
> > >
> > > I cannot figure out what can possibly cause this error in the XOBNEW 
> > > function.
> > >
> > > Please help!!!
> >
> > Don't use build_fake_var_decl, use what 4.6 did, create_tmp_var_raw.
> >
> > Richard.
> >
> >
>
> But 4.6 used get_var_ann() also along with create_tmp_var_raw()  which
> has been removed from 4.7.


I would like to clarify my above statement by saying that 4.6 used 2
functions [ie. create_tmp_var_raw() and get_var_ann()] whereas 4.7
used only one function [build_fake_var_decl()] for the same purpose.
Now in 4.7 get_var_ann() is unavailable. So is it safe to use only
create_tmp_var_raw(). In other words, was get_var_ann() a redundant
function in 4.6?


>
> > > Sudakshina Das

Re: mips16 and nomips16

2013-01-25 Thread Richard Sandiford 
"Maciej W. Rozycki"  writes:
> On Fri, 18 Jan 2013, Richard Sandiford wrote:
>
>> > I would assume that foo would be nomips16 and goo would be mips16.
>> >
>> > The definition of plain foo() or goo() says that nothing is specified.
>> >
>> > What is not clear then?
>> >
>> > This is how all such other attributes in gcc are handled.
>> 
>> Well, in a way, these are the only such attributes in GCC :-)
>> I don't think any other port supports switching between different
>> ISA modes like this.
>> 
>> I think the original authors really wanted "mips16" and "nomips16" to be
>> type attributes rather than decl attributes.  nomips16 function pointers
>> and mips16 function pointers would be mutually-incompatible subtypes of
>> unannotated function pointers, so you would be able to implicitly
>> convert an annotated function pointer to an unannotated one, but not the
>> other way, and not between annotated function pointers.  GCC didn't at
>> the time (and as far as I know still doesn't) have hooks to enforce that
>> though.  The attributes therefore ended up being implemented as strict
>> decl attributes in the hope that they could be made type attributes in
>> future without breaking backwards compatibility.
>> 
>> Not having those hooks means that the validity and semantics of:
>> 
>>  void foo();
>>  void __attribute((subtype)) foo();
>> 
>> aren't really defined.  Does foo() keep its original type or change to
>> the subtype?  It's also not defined whether:
>> 
>>  void __attribute((subtype)) foo();
>>  void foo();
>> 
>> is invalid, or whether the subtype from the first declaration carries
>> over to the second.  Etc.  (To be clear, I'm not trying to start a
>> discussion on the right semantics, or anything like that.  I'm just
>> saying that I don't think the semantics are defined yet, although
>> I could be wrong.)
>
>  FWIW, I think the benefit from these attributes being a type property is 
> questionable to say the least.  My understanding is the only application 
> is to prevent the tail-call optimisation from being applied to non-PIC 
> standard MIPS functions that otherwise would have to make a direct jump to 
> MIPS16 code for which there is no hardware support (note that there is no 
> issue with PIC code as with register jumps the ISA bit can be freely set 
> at will as required).

I think the main benefit was more to avoid unnecessary hard-float
interworking cruft.  If you're calling an indirect function (including
vtable function) whose type has a mips16 attribute, you know that
float values will be returned in GPRs without going through the
libgcc stub.  So...

>  If that is the case, then perhaps producing a suitable call thunk 
> instead, similar to these we use to pass floating-point arguments around 
> with MIPS16 functions or to call PIC code from non-PIC code statically 
> linked together, so that all standard MIPS code is link-time compatible 
> with MIPS16 would be a better option?

...I think the idea was to avoid this kind of overhead.

But like I say, I might be misrepresenting things, and I'm certainly open
to removing the check if there's agreement we don't want type attributes.

FWIW, there's also the "target" attribute, which is designed specifically
for turning options on and off at the function definition site, and which
also has an associated pragma for controlling a block of functions.
That isn't implemented yet for MIPS, but should be.  E.g. we could have
target("mips16"), target("no-mips16"), target("micromips") and
target("no-micromips").

So one alternative might be to keep the current attributes as they are
and implement "target".

Richard

Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0

2013-01-25 Thread Richard Biener 
On Thu, Jan 24, 2013 at 3:17 PM, Uday P. Khedker  wrote:
>
>
> Richard Biener wrote, On Thursday 24 January 2013 05:28 PM:
>
>
>>> In the program below, we have a global pointer p that has conditional
>>> assignments before its
>>> use on the RHS of a copy statement.
>>>
>>> -
>>> #include
>>>
>>> int **p;
>>> int main()
>>> {
>>>  int *x,*y,a,c,*z;
>>>  x = &a;
>>>  z = &c;
>>>  if(a)
>>>  p = &x;
>>>  else
>>>  p = &y;
>>>   int **t = p;
>>>   printf("%d,%d",*z,*x);
>>>}
>>>
>>> -
>>> The assignment t=p does not seem to load p inspite of p being a global
>>> pointer. Here's
>>> the relevant code fragment from test.c.017t.ssa:
>>>
>>> 
>>> :
>>>p = &x;
>>>goto ;
>>>
>>> :
>>>p = &y;
>>>
>>> :
>>>t_3 = p;
>>
>>
>> here p is loaded directly into t_3, you can consider it optimized
>> (copy propagated)
>> from
>>
>>D.1234_8 = p;
>>t_3 = D.1234_8;
>>
>>>x.1_4 = x;
>>>D.2524_5 = *x.1_4;
>>>D.2525_6 = *z_1;
>>>
>>> ---
>>> Note that p is global but it has been loaded neither loaded, nor does it
>>> have a PHI function.
>>
>>
>> As p resides in memory it does not need a PHI - values are merged by
>> storing them to memory.
>
>
> Yes, but because it is in memory, should it not be loaded? I thought every
> memory
> access is preceded by a load. At least that is how I interpreted your
> original statement.

My original statement was that if you have a memory access through a
pointer, *p, in C terms then p will be loaded into an SSA name first (if p is
not already an SSA name).  In your example p is not dereferenced.
Thus, more precise "every indirect memory access to *p is preceeded by a load
of the pointer p to an SSA name".

>
>>
>>> There is no way we can put the pointees of p in SSA_NAME_PTR_INFO of p in
>>> a
>>> flow sensitive
>>> manner.
>>>
>>> So if a later optimization pass were to find out aliases of p or pointees
>>> of
>>> p for the statement
>>> t_3 = p, I don't know how will we supply the information that was
>>> discovered
>>> by our analysis.
>>
>>
>> Your analysis should have come across that statement
>>
>>t_3 = p;
>>
>> and record that t_3 points to what p points to at this point of the
>> program,
>> thus compute a solution for all SSA name pointers.
>
>
> Yes that is easy to do. But my concern is what if there is a pass that
> requires/uses pointer
> information of p in the statement t_3 = p.

Then it would have no way of getting at it.  Likewise if there is a global x

struct { int i; int *p; double d; } x;

and a pass would want to get at pointer information of x.p.

But why would any pass want pointer information of p or x.p if there
is no use of p or x.p as pointer in the program?  And if there is, then
the pointer will be loaded to an SSA name and used as SSA name.
Thus the pass will never want to query pointer information on memory
but only on SSA names (as those are the only ones that get dereferenced
and thus used).

At least it should work 99% of the cases in this way - and I can't currently
think of an example for the remaining 1% - though I'm sure there may be
some obscure case.

>>
>> This is what the present points-to algorithm does, and at the end it
>> simply
>> discards anything but the solutions computed for SSA name pointers
>> which are stored in SSA_NAME_PTR_INFO.
>
>
> Oh, does it mean that the SSA_NAME_PTR_INFO would not be present for p
> but would be present only for t_3 (because p is not an SSA name and t_3 is)?

Yes.

> If this is true, can we assume the invariant that any pass would seek
> pointer
> info only for SSA names and not for any non-SSA name?

Yes, that is my belief.

> If that is the case, then I think there is a simple way in which we can make
> the
> result of our analysis available to all other passes without they having to
> consult our data structure.

Yes.

Richard.

>
> Uday.
>

Re: Remove node from cgraph

2013-01-25 Thread Richard Biener 
On Fri, Jan 25, 2013 at 8:57 AM, Chassin  wrote:
> On 01/24/2013 06:43 AM, Richard Biener wrote:
>>
>> On Thu, Jan 24, 2013 at 4:46 AM, Chassin 
>> wrote:
>>>
>>> On 01/23/2013 02:37 PM, Richard Biener wrote:

 Please keep this on the list.

 On Wed, Jan 23, 2013 at 5:52 PM, Chassin 
 wrote:
>
> On 01/23/2013 10:55 AM, Richard Biener wrote:
>
> The callgraph isn't the main data structure to modify here.  You
> probably
> still
> have references to the function in the IL via calls for example.  You
> probably
> want to remove all calls to the cgraph node.
>
> Thanks for the quick replay Sr , do you mean by removing calls the (
> edges )
> ? , but  by using cgraph_remove_node it seams to delete all callee and
> callers to that node
>
>
> 
> 01494   cgraph_node_remove_callers (node);
> 01495   cgraph_node_remove_callees (node);
> 01496   ipa_remove_all_references (&node->ref_list);
> 01497   ipa_remove_all_refering (&node->ref_list);
> ...
>
>
> in the dump file in my previous mail it shows that all edges related
> were
> removed , should i remove the reference in the GIMPLE body manually ?
> how
> ?

 You need to remove the call stmts - they are the main representation
 of the edges which
 get re-built when needed.  You can iterate over the call statements
 via the cgraph node
 callers list of edges.  In the cgraph edge structure you'll find a
 call_stmt member.  To
 remove it you need to switch to the corresponding function
 (push/pop_cfun,
 use
 DECL_STRUCT_FUNCTION (edge->caller->decl)) and then remove the stmt via
 for example gsi_remove () after initializing an iterator via
 gsi_for_stmt.

 That's not all of the details, you of course have to think of what to
 do for other
 references to the function (function pointers and later indirect
 calls).  You have to
 think about what the point is of removing arbitrary calls throughout a
 program
 of course - I can't see any good reason to do this kind of stuff ;)

 Richard.

> cheers
>
> --
> Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu
>
> Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
> Informatics Engineering Faculty
>
> 48 Aniversario del Instituto Superior Politécnico José Antonio
> Echeverría,
> Cujae Una obra de la Revolución Cubana | 2 de diciembre de 1964 |
> http://cujae.edu.cu
>
>
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>>>
>>> Hi Ms.Richard , i am new to gcc , i got confused so by removing the edge
>>> i
>>> am really not doing anything !!! cuz if the call stmt still exist , did i
>>> understood right ?
>>> if so then what really the edge represent ??
>>
>> Callgraph nodes and callgraph edges are a representation of functions
>> and call statements.  The functions with their statements are the main
>> representation of the intermediate language ontop of which other
>> high-level data structures are built.  The functions and their statements
>> are the representation to change.
>>
>>> , can you provide me a sample
>>> code how to do that ?
>>
>> No, because it's quite a nonsensical operation so there doesn't exist
>> an example in GCC itself I can point you to.
>>
>> Please do not continue to ask me questions privately, but post questions
>> on the mailing-list.  This way other people can benefit as well from your
>> questions and answers you get.
>>
>> Richard.
>>
>>> thnx for your time
>>>
>>>
>>> --
>>> Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu
>>>
>>> Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
>>> Informatics Engineering Faculty
>>>
>>>
>>>
>>> 48 Aniversario del Instituto Superior Politecnico Jose Antonio
>>> Echeverria,
>>> Cujae
>>> Una obra de la Revolucion Cubana | 2 de diciembre de 1964 |
>>> http://cujae.edu.cu
>>>
>>>
>>>
>>>
>>> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
> Richard thnx for your feedbacks i managed to code the function here i
> provide a sample ,
>
> // This will remove just one call but i think with this we can get a
> start point to manage how to delete all other references
> char *in_str="main";
> char *to_str="f_1";
> struct cgraph_node *in_node = util_get_cgnode_by_name(in_str);
> struct cgraph_node *to_node = util_get_cgnode_by_name(to_str);
> struct cgraph_edge *edge=
> util_get_cgedge_matches_first_call(in_node,to_node);
>
> push_cfun(DECL_STRUCT_FUNCTION(in_node->decl));
> int i=0;
> basic_block bb;
> gimple_stmt_iterator gsi;
> gimple stmt;
>
> // itearte over the basic block in the current function pushed
> FOR_EACH_BB(bb)
> for (gsi=gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi))
> {
> stmt = gsi_stmt(gsi);
> if(stmt == edge->cal

Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2

2013-01-25 Thread Richard Biener 
On Fri, Jan 25, 2013 at 3:05 PM, Sudakshina Das
 wrote:
> On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
>  wrote:
>>
>> On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
>>  wrote:
>> >
>> > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
>> >  wrote:
>> > > Dear all,
>> > >
>> > > I am currently updating a pass that was made for gcc-4.6.*, so that it
>> > > works for gcc.4.7.2.
>> > >
>> > > In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
>> > > was picked up and used.
>> > > Given below is the fragment taken form create_function_info_for () .
>> > > This fragment was used to create variable information for the function
>> > > and it was picked up to perform a similar operation in the added pass
>> > > as well.
>> > >
>> > > But in gcc-4.7.2 some changes are introduced in the fragment. The code
>> > > given below shows the changes that have been introduced in
>> > > create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
>> > > along with the original code in the comments.
>> > >
>> > >   /* Add one representative for all further args.  */
>> > >   if (is_varargs)
>> > > {
>> > >   varinfo_t argvi;
>> > >   const char *newname;
>> > >   char *tempname;
>> > >   tree decl;
>> > >
>> > >   asprintf (&tempname, "%s.varargs", name);
>> > >   newname = ggc_strdup (tempname);
>> > >   free (tempname);
>> > >
>> > >   /* We need sth that can be pointed to for va_start.  */
>> > >
>> > > / CHANGED CODE in GCC-4.7.2 ***/
>> > >   decl = build_fake_var_decl (ptr_type_node);
>> > >
>> > > / ORIGINAL CODE in GCC-4.6.2 ***
>> > > /*  decl = create_tmp_var_raw (ptr_type_node, name);
>> > > get_var_ann (decl);
>> > > */
>> > >
>> > >   argvi = new_var_info (decl, newname);
>> > >   argvi->offset = fi_parm_base + num_args;
>> > >   argvi->size = ~0;
>> > >   argvi->is_full_var = true;
>> > >   argvi->is_heap_var = true;
>> > >   argvi->fullsize = vi->fullsize;
>> > >   gcc_assert (prev_vi->offset < argvi->offset);
>> > >   prev_vi->next = argvi;
>> > >   prev_vi = argvi;
>> > > }
>> > >
>> > >   return vi;
>> > >
>> > >
>> > > So I made the same changes in the pass where this fragment was used.
>> > > But after making the changes the pass is now giving an "internal
>> > > compiler error" and a "segmentation fault" at runtime.
>> > >
>> > > After debugging I could narrow it down to the function
>> > > build_fake_var_decl() and to be specific at the memory allocation
>> > > statement highlighted below.
>> > >
>> > >
>> > > tree
>> > > build_fake_var_decl (tree type)
>> > > {
>> > > / My debugging showed that the control came
>> > > here */
>> > >   tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct 
>> > > tree_var_decl);
>> > > / But did not come here
>> > > **/
>> > >   memset (decl, 0, sizeof (struct tree_var_decl));
>> > >   TREE_SET_CODE (decl, VAR_DECL);
>> > >   TREE_TYPE (decl) = type;
>> > >   DECL_UID (decl) = allocate_decl_uid ();
>> > >   SET_DECL_PT_UID (decl, -1);
>> > >   layout_decl (decl, 0);
>> > >   return decl;
>> > > }
>> > >
>> > > The builf_fake_var_decl() function is a gcc function defined in
>> > > tree-ssa-structalias.c. To be able to use it in my pass, I removed the
>> > > keyword static in its definition.
>> > >
>> > > I cannot figure out what can possibly cause this error in the XOBNEW 
>> > > function.
>> > >
>> > > Please help!!!
>> >
>> > Don't use build_fake_var_decl, use what 4.6 did, create_tmp_var_raw.
>> >
>> > Richard.
>> >
>> >
>>
>> But 4.6 used get_var_ann() also along with create_tmp_var_raw()  which
>> has been removed from 4.7.
>
>
> I would like to clarify my above statement by saying that 4.6 used 2
> functions [ie. create_tmp_var_raw() and get_var_ann()] whereas 4.7
> used only one function [build_fake_var_decl()] for the same purpose.
> Now in 4.7 get_var_ann() is unavailable. So is it safe to use only
> create_tmp_var_raw(). In other words, was get_var_ann() a redundant
> function in 4.6?

The whole function is very special for tree-ssa-structalias.c.  I have no idea
what your pass does, but unless it closely resembles tree-ssa-structalias.c
and shares its internal data structures you shouldn't blindly copy over what
tree-ssa-structalias.c does (well, at least not without understanding what you
are doing).

What do you think you are doing with the copy of that code?

Richard.

>
>>
>> > > Sudakshina Das

Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2

2013-01-25 Thread Sudakshina Das 
On Fri, Jan 25, 2013 at 8:02 PM, Richard Biener
 wrote:
> On Fri, Jan 25, 2013 at 3:05 PM, Sudakshina Das
>  wrote:
>> On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
>>  wrote:
>>>
>>> On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
>>>  wrote:
>>> >
>>> > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
>>> >  wrote:
>>> > > Dear all,
>>> > >
>>> > > I am currently updating a pass that was made for gcc-4.6.*, so that it
>>> > > works for gcc.4.7.2.
>>> > >
>>> > > In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
>>> > > was picked up and used.
>>> > > Given below is the fragment taken form create_function_info_for () .
>>> > > This fragment was used to create variable information for the function
>>> > > and it was picked up to perform a similar operation in the added pass
>>> > > as well.
>>> > >
>>> > > But in gcc-4.7.2 some changes are introduced in the fragment. The code
>>> > > given below shows the changes that have been introduced in
>>> > > create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
>>> > > along with the original code in the comments.
>>> > >
>>> > >   /* Add one representative for all further args.  */
>>> > >   if (is_varargs)
>>> > > {
>>> > >   varinfo_t argvi;
>>> > >   const char *newname;
>>> > >   char *tempname;
>>> > >   tree decl;
>>> > >
>>> > >   asprintf (&tempname, "%s.varargs", name);
>>> > >   newname = ggc_strdup (tempname);
>>> > >   free (tempname);
>>> > >
>>> > >   /* We need sth that can be pointed to for va_start.  */
>>> > >
>>> > > / CHANGED CODE in GCC-4.7.2 ***/
>>> > >   decl = build_fake_var_decl (ptr_type_node);
>>> > >
>>> > > / ORIGINAL CODE in GCC-4.6.2 ***
>>> > > /*  decl = create_tmp_var_raw (ptr_type_node, name);
>>> > > get_var_ann (decl);
>>> > > */
>>> > >
>>> > >   argvi = new_var_info (decl, newname);
>>> > >   argvi->offset = fi_parm_base + num_args;
>>> > >   argvi->size = ~0;
>>> > >   argvi->is_full_var = true;
>>> > >   argvi->is_heap_var = true;
>>> > >   argvi->fullsize = vi->fullsize;
>>> > >   gcc_assert (prev_vi->offset < argvi->offset);
>>> > >   prev_vi->next = argvi;
>>> > >   prev_vi = argvi;
>>> > > }
>>> > >
>>> > >   return vi;
>>> > >
>>> > >
>>> > > So I made the same changes in the pass where this fragment was used.
>>> > > But after making the changes the pass is now giving an "internal
>>> > > compiler error" and a "segmentation fault" at runtime.
>>> > >
>>> > > After debugging I could narrow it down to the function
>>> > > build_fake_var_decl() and to be specific at the memory allocation
>>> > > statement highlighted below.
>>> > >
>>> > >
>>> > > tree
>>> > > build_fake_var_decl (tree type)
>>> > > {
>>> > > / My debugging showed that the control came
>>> > > here */
>>> > >   tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct 
>>> > > tree_var_decl);
>>> > > / But did not come here
>>> > > **/
>>> > >   memset (decl, 0, sizeof (struct tree_var_decl));
>>> > >   TREE_SET_CODE (decl, VAR_DECL);
>>> > >   TREE_TYPE (decl) = type;
>>> > >   DECL_UID (decl) = allocate_decl_uid ();
>>> > >   SET_DECL_PT_UID (decl, -1);
>>> > >   layout_decl (decl, 0);
>>> > >   return decl;
>>> > > }
>>> > >
>>> > > The builf_fake_var_decl() function is a gcc function defined in
>>> > > tree-ssa-structalias.c. To be able to use it in my pass, I removed the
>>> > > keyword static in its definition.
>>> > >
>>> > > I cannot figure out what can possibly cause this error in the XOBNEW 
>>> > > function.
>>> > >
>>> > > Please help!!!
>>> >
>>> > Don't use build_fake_var_decl, use what 4.6 did, create_tmp_var_raw.
>>> >
>>> > Richard.
>>> >
>>> >
>>>
>>> But 4.6 used get_var_ann() also along with create_tmp_var_raw()  which
>>> has been removed from 4.7.
>>
>>
>> I would like to clarify my above statement by saying that 4.6 used 2
>> functions [ie. create_tmp_var_raw() and get_var_ann()] whereas 4.7
>> used only one function [build_fake_var_decl()] for the same purpose.
>> Now in 4.7 get_var_ann() is unavailable. So is it safe to use only
>> create_tmp_var_raw(). In other words, was get_var_ann() a redundant
>> function in 4.6?
>
> The whole function is very special for tree-ssa-structalias.c.  I have no idea
> what your pass does, but unless it closely resembles tree-ssa-structalias.c
> and shares its internal data structures you shouldn't blindly copy over what
> tree-ssa-structalias.c does (well, at least not without understanding what you
> are doing).
>
> What do you think you are doing with the copy of that code?
>
> Richard.
>
>>
>>>


The copy of the above code is from function create_function_info_for()
in tree-ssa-structalias.c which is used to create variables for a
function in its tree. In the pass there is a similar function

Re: Question on lower-subreg.c

2013-01-25 Thread Ian Lance Taylor 
On Thu, Jan 24, 2013 at 11:57 PM, Bin.Cheng  wrote:
>
> I read code in lower-subreg.c and found GCC only split some of
> multi-word mode instructions, like load from memory into pseudo reg,
> etc. The related code is in find_decomposable_subregs.
>
> So for below example from PR56102:
>
> double g = 1.0;
> double func(int a, double d)
> {
> if (a > 0)
> return 0.0 + g;
> else
> return 2.0 + d;
> }
>
> compiling with:
> ./arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os test.c -S -o test.S
>
> If split is done for all DFmode insns, it will save us code size by
> sharing constant pool in program.

On most platforms that would hurt performance, because most platforms
have a single instruction to load and store a DFmode value into a
floating point register.  In fact I suspect that transformation would
be a poor choice on any target that has 64-bit floating point
registers at all.

it would be a reasonable optimization for a target that has no
floating point registers and that stores all DFmode values as a pair
of 32-bit registers.  If you care about such a target, it would be
reasonable to add support to lower-subreg for that case.

Ian

autovectorizer doesn't support multistep widen mult

2013-01-25 Thread Paulo Matos 
Hello,

Is there any technical reason (besides nobody bothers to implement it) why GCC 
doesn't support multistep conversions for widen mult?

In tree-vect-stmts.c:
  /* Check if it's a multi-step conversion that can be done using intermediate
 types.  */

  prev_type = vectype;
  prev_mode = vec_mode;

  if (!CONVERT_EXPR_CODE_P (code))
return false;

Is there any reason we only proceed for convert expr codes?

Thanks,

Paulo Matos

Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2

2013-01-25 Thread Richard Biener 
On Fri, Jan 25, 2013 at 3:57 PM, Sudakshina Das
 wrote:
> On Fri, Jan 25, 2013 at 8:02 PM, Richard Biener
>  wrote:
>> On Fri, Jan 25, 2013 at 3:05 PM, Sudakshina Das
>>  wrote:
>>> On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
>>>  wrote:

 On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
  wrote:
 >
 > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
 >  wrote:
 > > Dear all,
 > >
 > > I am currently updating a pass that was made for gcc-4.6.*, so that it
 > > works for gcc.4.7.2.
 > >
 > > In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
 > > was picked up and used.
 > > Given below is the fragment taken form create_function_info_for () .
 > > This fragment was used to create variable information for the function
 > > and it was picked up to perform a similar operation in the added pass
 > > as well.
 > >
 > > But in gcc-4.7.2 some changes are introduced in the fragment. The code
 > > given below shows the changes that have been introduced in
 > > create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
 > > along with the original code in the comments.
 > >
 > >   /* Add one representative for all further args.  */
 > >   if (is_varargs)
 > > {
 > >   varinfo_t argvi;
 > >   const char *newname;
 > >   char *tempname;
 > >   tree decl;
 > >
 > >   asprintf (&tempname, "%s.varargs", name);
 > >   newname = ggc_strdup (tempname);
 > >   free (tempname);
 > >
 > >   /* We need sth that can be pointed to for va_start.  */
 > >
 > > / CHANGED CODE in GCC-4.7.2 ***/
 > >   decl = build_fake_var_decl (ptr_type_node);
 > >
 > > / ORIGINAL CODE in GCC-4.6.2 ***
 > > /*  decl = create_tmp_var_raw (ptr_type_node, name);
 > > get_var_ann (decl);
 > > */
 > >
 > >   argvi = new_var_info (decl, newname);
 > >   argvi->offset = fi_parm_base + num_args;
 > >   argvi->size = ~0;
 > >   argvi->is_full_var = true;
 > >   argvi->is_heap_var = true;
 > >   argvi->fullsize = vi->fullsize;
 > >   gcc_assert (prev_vi->offset < argvi->offset);
 > >   prev_vi->next = argvi;
 > >   prev_vi = argvi;
 > > }
 > >
 > >   return vi;
 > >
 > >
 > > So I made the same changes in the pass where this fragment was used.
 > > But after making the changes the pass is now giving an "internal
 > > compiler error" and a "segmentation fault" at runtime.
 > >
 > > After debugging I could narrow it down to the function
 > > build_fake_var_decl() and to be specific at the memory allocation
 > > statement highlighted below.
 > >
 > >
 > > tree
 > > build_fake_var_decl (tree type)
 > > {
 > > / My debugging showed that the control came
 > > here */
 > >   tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct 
 > > tree_var_decl);
 > > / But did not come here
 > > **/
 > >   memset (decl, 0, sizeof (struct tree_var_decl));
 > >   TREE_SET_CODE (decl, VAR_DECL);
 > >   TREE_TYPE (decl) = type;
 > >   DECL_UID (decl) = allocate_decl_uid ();
 > >   SET_DECL_PT_UID (decl, -1);
 > >   layout_decl (decl, 0);
 > >   return decl;
 > > }
 > >
 > > The builf_fake_var_decl() function is a gcc function defined in
 > > tree-ssa-structalias.c. To be able to use it in my pass, I removed the
 > > keyword static in its definition.
 > >
 > > I cannot figure out what can possibly cause this error in the XOBNEW 
 > > function.
 > >
 > > Please help!!!
 >
 > Don't use build_fake_var_decl, use what 4.6 did, create_tmp_var_raw.
 >
 > Richard.
 >
 >

 But 4.6 used get_var_ann() also along with create_tmp_var_raw()  which
 has been removed from 4.7.
>>>
>>>
>>> I would like to clarify my above statement by saying that 4.6 used 2
>>> functions [ie. create_tmp_var_raw() and get_var_ann()] whereas 4.7
>>> used only one function [build_fake_var_decl()] for the same purpose.
>>> Now in 4.7 get_var_ann() is unavailable. So is it safe to use only
>>> create_tmp_var_raw(). In other words, was get_var_ann() a redundant
>>> function in 4.6?
>>
>> The whole function is very special for tree-ssa-structalias.c.  I have no 
>> idea
>> what your pass does, but unless it closely resembles tree-ssa-structalias.c
>> and shares its internal data structures you shouldn't blindly copy over what
>> tree-ssa-structalias.c does (well, at least not without understanding what 
>> you
>> are doing).
>>
>> What do you think you are doing with the copy of that code?
>>
>> Richard.
>>
>>>

>
>

Re: autovectorizer doesn't support multistep widen mult

2013-01-25 Thread Richard Biener 
On Fri, Jan 25, 2013 at 4:13 PM, Paulo Matos  wrote:
> Hello,
>
> Is there any technical reason (besides nobody bothers to implement it) why 
> GCC doesn't support multistep conversions for widen mult?

No.

> In tree-vect-stmts.c:
>   /* Check if it's a multi-step conversion that can be done using intermediate
>  types.  */
>
>   prev_type = vectype;
>   prev_mode = vec_mode;
>
>   if (!CONVERT_EXPR_CODE_P (code))
> return false;
>
> Is there any reason we only proceed for convert expr codes?

Because others are not a conversion?!

> Thanks,
>
> Paulo Matos
>
>

RE: autovectorizer doesn't support multistep widen mult

2013-01-25 Thread Paulo Matos 

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 25 January 2013 15:59
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: autovectorizer doesn't support multistep widen mult
> 
> On Fri, Jan 25, 2013 at 4:13 PM, Paulo Matos  wrote:
> > Hello,
> >
> > Is there any technical reason (besides nobody bothers to implement it) why
> GCC doesn't support multistep conversions for widen mult?
> 
> No.
> 

Thanks, that's what I needed to know.

> > In tree-vect-stmts.c:
> >   /* Check if it's a multi-step conversion that can be done using
> intermediate
> >  types.  */
> >
> >   prev_type = vectype;
> >   prev_mode = vec_mode;
> >
> >   if (!CONVERT_EXPR_CODE_P (code))
> > return false;
> >
> > Is there any reason we only proceed for convert expr codes?
> 
> Because others are not a conversion?!
> 

My question here was really just repetition of the above using other words. 
Your answer matches my expectations. :)

Thanks,

Re: gcc : c++11 : full support : eta?

2013-01-25 Thread Uday P. Khedker 



Paolo Bonzini wrote, On Friday 25 January 2013 05:38 PM:

Il 25/01/2013 08:24, Uday P. Khedker ha scritto:

Exactly. We have been using our training program since 2007 (and have
been incrementally refining it on a continuously). Our experience has
been that it has brought down the ramp up period of novices to a couple
of week.


A couple of weeks is really unbelievable.  Congratulations!



Thanks!

Yes, it does look incredible but the material at 
http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ was developed over four years 
and has been continuously refined for five years (so it is a nine years' effort 
on part of my group).

Some of my most brilliant minds toiled hard to ask simple questions eg. what is 
the _minimal_ machine description for GCC, how can we incrementally refine 
machine descriptions, can machine descriptions be any simpler, what are the 
programming assignments that one should do to be sufficiently independent (and 
ask meaningful questions on the gcc mailing list!), what is the overall 
structure of the compiler generator, what is the overall structure of the 
generated compiler, what is the retargetability mechanism (i.e. what is the 
relationship of the md file with the generated compiler) etc.

We had to find the right balance between details and concepts and that is what took most of the time. We did 
not want "information" to be the focus. We wanted the "understanding of the learner" to 
be the main focus. The training program is called "Essential Abstractions in GCC"; all of which are 
summarized in 
http://www.cse.iitb.ac.in/grc/gcc-workshop-12/downloads/slides/gccw12-essential-abstractions.pdf.

Needless to say, there is a lot of scope for improvement :-)

I would be happy if this becomes acceptable as the first course in GCC. A side 
benefit of doing so is that then it will be easier for me to pick the minds of 
the developers for improving it :-)

Uday.

P.S. : May be I am belabouring the point, but for me there is a lot of 
difference between the following two responses:

   (a) "You are free to develop any training material and hook it up via gcc 
wiki".
   (b) "Let us adopt this as the first course and we all will give inputs on how 
it can be refined and made better".

   Response (a) is a tautology but it also limits the reach and the 
effectiveness of the course. It also contributes to confusing a newcomer.
--
--
Dr. Uday Khedker
Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
Email   :   u...@cse.iitb.ac.in
Homepage:   http://www.cse.iitb.ac.in/~uday
Phone   :   
Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
Res.   -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)

Re: gcc : c++11 : full support : eta?

2013-01-25 Thread Gabriel Dos Reis 
On Thu, Jan 24, 2013 at 1:59 PM, Jeff Law  wrote:
> On 01/24/2013 12:55 PM, Diego Novillo wrote:
>>
>>
>> I do see, however, a few areas where Clang/LLVM have gone that I do
>> not think GCC is currently thinking of entering: "toolability" (for
>> the lack of a better term).  Clang's design follows a different path
>> than g++.  It's not just a code generating parser, it is a pure parser
>> that also generates code.  The difference makes it suitable for any
>> kind of tool that needs to understand C++: static analyzers, code
>> re-formatters, syntax highlighters, and other similar tools.
>> Additionally, it is designed as a library, so it can be embedded into
>> applications.
>
> Yup.  We kicked stuff in this area around as well as we were discussing the
> problems early folding presents.  In an ideal world, the G++ parser would
> turn into something that can be used not just for G++, but as a library for
> other tools that need to parse C++ code (doxygen, gdb and I'm sure there's
> others).

First all of I should confess that I have had long
interest in having a "modular" g++ parser in the
sense that I would like the ability to retarget it to
other purposes that we cannot realistically expect
a single simple C++ compiler to satisfy simultaneously.

However parsing C++ is a very tricky.  Depending
on the level of fidelity to the C++ spec, parsing involves
template instantiation, which itself may involve overload
resolution, etc.  So when we are talking about a C++ parser
module, this means we need a much better typed AST to represent
the semantics graph before gimplification.

-- Gaby

Re: Remove node from cgraph

2013-01-25 Thread Chassin 

On 01/25/2013 09:21 AM, Richard Biener wrote:

On Fri, Jan 25, 2013 at 8:57 AM, Chassin  wrote:

On 01/24/2013 06:43 AM, Richard Biener wrote:

On Thu, Jan 24, 2013 at 4:46 AM, Chassin 
wrote:

On 01/23/2013 02:37 PM, Richard Biener wrote:

Please keep this on the list.

On Wed, Jan 23, 2013 at 5:52 PM, Chassin 
wrote:

On 01/23/2013 10:55 AM, Richard Biener wrote:

The callgraph isn't the main data structure to modify here.  You
probably
still
have references to the function in the IL via calls for example.  You
probably
want to remove all calls to the cgraph node.

Thanks for the quick replay Sr , do you mean by removing calls the (
edges )
? , but  by using cgraph_remove_node it seams to delete all callee and
callers to that node



01494   cgraph_node_remove_callers (node);
01495   cgraph_node_remove_callees (node);
01496   ipa_remove_all_references (&node->ref_list);
01497   ipa_remove_all_refering (&node->ref_list);
...


in the dump file in my previous mail it shows that all edges related
were
removed , should i remove the reference in the GIMPLE body manually ?
how
?

You need to remove the call stmts - they are the main representation
of the edges which
get re-built when needed.  You can iterate over the call statements
via the cgraph node
callers list of edges.  In the cgraph edge structure you'll find a
call_stmt member.  To
remove it you need to switch to the corresponding function
(push/pop_cfun,
use
DECL_STRUCT_FUNCTION (edge->caller->decl)) and then remove the stmt via
for example gsi_remove () after initializing an iterator via
gsi_for_stmt.

That's not all of the details, you of course have to think of what to
do for other
references to the function (function pointers and later indirect
calls).  You have to
think about what the point is of removing arbitrary calls throughout a
program
of course - I can't see any good reason to do this kind of stuff ;)

Richard.


cheers

--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty

48 Aniversario del Instituto Superior Politécnico José Antonio
Echeverría,
Cujae Una obra de la Revolución Cubana | 2 de diciembre de 1964 |
http://cujae.edu.cu


Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

Hi Ms.Richard , i am new to gcc , i got confused so by removing the edge
i
am really not doing anything !!! cuz if the call stmt still exist , did i
understood right ?
if so then what really the edge represent ??

Callgraph nodes and callgraph edges are a representation of functions
and call statements.  The functions with their statements are the main
representation of the intermediate language ontop of which other
high-level data structures are built.  The functions and their statements
are the representation to change.


, can you provide me a sample
code how to do that ?

No, because it's quite a nonsensical operation so there doesn't exist
an example in GCC itself I can point you to.

Please do not continue to ask me questions privately, but post questions
on the mailing-list.  This way other people can benefit as well from your
questions and answers you get.

Richard.


thnx for your time


--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty



48 Aniversario del Instituto Superior Politecnico Jose Antonio
Echeverria,
Cujae
Una obra de la Revolucion Cubana | 2 de diciembre de 1964 |
http://cujae.edu.cu




Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

Richard thnx for your feedbacks i managed to code the function here i
provide a sample ,

 // This will remove just one call but i think with this we can get a
start point to manage how to delete all other references
 char *in_str="main";
 char *to_str="f_1";
 struct cgraph_node *in_node = util_get_cgnode_by_name(in_str);
 struct cgraph_node *to_node = util_get_cgnode_by_name(to_str);
 struct cgraph_edge *edge=
util_get_cgedge_matches_first_call(in_node,to_node);

 push_cfun(DECL_STRUCT_FUNCTION(in_node->decl));
 int i=0;
 basic_block bb;
 gimple_stmt_iterator gsi;
 gimple stmt;

 // itearte over the basic block in the current function pushed
 FOR_EACH_BB(bb)
 for (gsi=gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi))
 {
 stmt = gsi_stmt(gsi);
 if(stmt == edge->call_stmt)

The loops can be replaced with

 gsi = gsi_for_stmt (edge->call_stmt);


 {
 gsi_remove((&gsi), true); // remove the stmt
 }
 }

 cgraph_remove_edge(edge);


 Sample  APP calls Before
 main -> f_1
 After
 main


--
Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu

Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’
Informatics Engineering Faculty



48 Aniversario del Instituto Superior Politecnico Jose Antonio Echeverria,
Cujae
Una obra de la

Re: A pass that worked in gcc-4.6.2 fails in gcc-4.7.2

2013-01-25 Thread Sudakshina Das 
On Fri, Jan 25, 2013 at 9:27 PM, Richard Biener
 wrote:
> On Fri, Jan 25, 2013 at 3:57 PM, Sudakshina Das
>  wrote:
>> On Fri, Jan 25, 2013 at 8:02 PM, Richard Biener
>>  wrote:
>>> On Fri, Jan 25, 2013 at 3:05 PM, Sudakshina Das
>>>  wrote:
 On Fri, Jan 25, 2013 at 9:46 AM, Sudakshina Das
  wrote:
>
> On Thu, Jan 24, 2013 at 5:15 PM, Richard Biener
>  wrote:
> >
> > On Thu, Jan 24, 2013 at 7:06 AM, Sudakshina Das
> >  wrote:
> > > Dear all,
> > >
> > > I am currently updating a pass that was made for gcc-4.6.*, so that it
> > > works for gcc.4.7.2.
> > >
> > > In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
> > > was picked up and used.
> > > Given below is the fragment taken form create_function_info_for () .
> > > This fragment was used to create variable information for the function
> > > and it was picked up to perform a similar operation in the added pass
> > > as well.
> > >
> > > But in gcc-4.7.2 some changes are introduced in the fragment. The code
> > > given below shows the changes that have been introduced in
> > > create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
> > > along with the original code in the comments.
> > >
> > >   /* Add one representative for all further args.  */
> > >   if (is_varargs)
> > > {
> > >   varinfo_t argvi;
> > >   const char *newname;
> > >   char *tempname;
> > >   tree decl;
> > >
> > >   asprintf (&tempname, "%s.varargs", name);
> > >   newname = ggc_strdup (tempname);
> > >   free (tempname);
> > >
> > >   /* We need sth that can be pointed to for va_start.  */
> > >
> > > / CHANGED CODE in GCC-4.7.2 ***/
> > >   decl = build_fake_var_decl (ptr_type_node);
> > >
> > > / ORIGINAL CODE in GCC-4.6.2 ***
> > > /*  decl = create_tmp_var_raw (ptr_type_node, name);
> > > get_var_ann (decl);
> > > */
> > >
> > >   argvi = new_var_info (decl, newname);
> > >   argvi->offset = fi_parm_base + num_args;
> > >   argvi->size = ~0;
> > >   argvi->is_full_var = true;
> > >   argvi->is_heap_var = true;
> > >   argvi->fullsize = vi->fullsize;
> > >   gcc_assert (prev_vi->offset < argvi->offset);
> > >   prev_vi->next = argvi;
> > >   prev_vi = argvi;
> > > }
> > >
> > >   return vi;
> > >
> > >
> > > So I made the same changes in the pass where this fragment was used.
> > > But after making the changes the pass is now giving an "internal
> > > compiler error" and a "segmentation fault" at runtime.
> > >
> > > After debugging I could narrow it down to the function
> > > build_fake_var_decl() and to be specific at the memory allocation
> > > statement highlighted below.
> > >
> > >
> > > tree
> > > build_fake_var_decl (tree type)
> > > {
> > > / My debugging showed that the control came
> > > here */
> > >   tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct 
> > > tree_var_decl);
> > > / But did not come here
> > > **/
> > >   memset (decl, 0, sizeof (struct tree_var_decl));
> > >   TREE_SET_CODE (decl, VAR_DECL);
> > >   TREE_TYPE (decl) = type;
> > >   DECL_UID (decl) = allocate_decl_uid ();
> > >   SET_DECL_PT_UID (decl, -1);
> > >   layout_decl (decl, 0);
> > >   return decl;
> > > }
> > >
> > > The builf_fake_var_decl() function is a gcc function defined in
> > > tree-ssa-structalias.c. To be able to use it in my pass, I removed the
> > > keyword static in its definition.
> > >
> > > I cannot figure out what can possibly cause this error in the XOBNEW 
> > > function.
> > >
> > > Please help!!!
> >
> > Don't use build_fake_var_decl, use what 4.6 did, create_tmp_var_raw.
> >
> > Richard.
> >
> >
>
> But 4.6 used get_var_ann() also along with create_tmp_var_raw()  which
> has been removed from 4.7.


 I would like to clarify my above statement by saying that 4.6 used 2
 functions [ie. create_tmp_var_raw() and get_var_ann()] whereas 4.7
 used only one function [build_fake_var_decl()] for the same purpose.
 Now in 4.7 get_var_ann() is unavailable. So is it safe to use only
 create_tmp_var_raw(). In other words, was get_var_ann() a redundant
 function in 4.6?
>>>
>>> The whole function is very special for tree-ssa-structalias.c.  I have no 
>>> idea
>>> what your pass does, but unless it closely resembles tree-ssa-structalias.c
>>> and shares its internal data structures you shouldn't blindly copy over what
>>> tree-ssa-str

gcc-4.6-20130125 is now available

2013-01-25 Thread gccadmin 
Snapshot gcc-4.6-20130125 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20130125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 195477

You'll find:

 gcc-4.6-20130125.tar.bz2 Complete GCC

  MD5=1210355fdb1d9826793b9b334684d209
  SHA1=ff1ce577a4e573a8d76af1c4873237f54461588d

Diffs from 4.6-20130118 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.