This is the mail archive of the
mailing list for the GCC project.
Re: [tree-profiling-branch PATCH] Function cloning + IPCP extension
- From: Jan Hubicka <jh at suse dot cz>
- To: Razya Ladelsky <RAZYA at il dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, stevenb at suse dot de, hubicka at ucw dot cz,Mircea Namolaru <NAMOLARU at il dot ibm dot com>, Ayal Zaks <ZAKS at il dot ibm dot com>,Revital Eres <ERES at il dot ibm dot com>
- Date: Mon, 25 Oct 2004 18:17:16 +0200
- Subject: Re: [tree-profiling-branch PATCH] Function cloning + IPCP extension
- References: <OFA5E7B090.E94D30A6-ONC2256F38.004FDEC8-C2256F38.005032DC@il.ibm.com>
> Following our message
> we attach the patch including several fixes and improvements.
> We added a new directory testsuite/gcc.dg/ipa for ipa testcases
> (ipa-1.c, ipa-2.c) and also new scancgraph.exp in testsuite/lib/
> to scan the cgraph dump file, which is (temporarily) the ipa dump file.
the cgraph interface bits now loks fine with me as does the changes to
inliner, however as Steven already mentioned we do have conflict here
with the cfg inlining patch. Since that patch is much more dificult to
maintain and affects other development, I think it make sense to wait
with your patch assuming that the inliner bits won't take too long to be
I however have some minor concerns about the ipcp implementation itself
(the overall algorithm seems to be what common textbooks describe,
right? If you made some significant/interesting changes or
implementation decisions over the paper you reffer to, please list those
in the introduction comment), there are few issues that I think needs to
be addressed before this code is considered ready for mainline:
1) getting debugging to work - I see there are FIXMEs disabling the
debug info being output at all. I am not really debugging expert, so I
hope you can discuss this with Jason and get it into workable shape.
Debugging is really pre-requisite for every optimization pass that want
to go into mainline. Please try to at least englighten me what the
problem is about...
2) as I mentioned elsewhere, we need to conclude on commmon programming
stype. Local renaming of types like:
typedef struct cgraph_node *ipcp_method ;
typedef struct cgraph_edge *ipcp_callsite;
is really not good idea as most people will be likely familiar with the
global names but not the local names
3) we need to update the code for the passmanager interface and probably
bit move around the memory management issues.
I think that everything except for perhaps 1) is quite minor task, so I
will be happy to see this done incrementally once we get ready to apply
your patch this or next week.
> Razya and Revital.