Re: [trans-mem] cgraph edges vs function cloning
> On 07/28/2009 10:44 AM, Richard Henderson wrote: > >I guess I'll poke at cleaning this up today. I've got to > >familiarize myself with how virtual clones work... > > The virtual clones that ipa-cp makes seems to be easy. > > My thought here is that since (virtual) clones don't > have actual bodies (and when they acquire bodies they > cease to be clones), then there's no reason for them > to have callee edges at all. If you want the list of > callees for a clone, you look at node->clone_of->callees. > In this way, when we materialize a clone, we don't have > to go looking for (and updating) edges, we just create > them as we copy the statements. This is not quite true, you can take function, clone it and then clone one of callees. Now one call to callee might need to point to original, while other to the clone. To represent this and similar transforms you need different set of edges for each clone. Also the goal is to make clones appear as much as real functions as possible for the optimizations, so they don't need to deal with too many special cases. > > What I don't understand is how the inliner uses clones. > Can you explain this? We don't apply inlining decisions at the time inliner decide inline A to B. Instead inline clone A is created and B's edge to A is redirected to this clone to represent that later we will duplicate the body and inline it into the function. Also concerning your code, please note that clonning never created identical copies, we had some problems here with saving for inlining. Since we in general leave statements unfolded in various occasions and inliner folds on handling some codes, we sometimes end up rendering part of functions unreachable and removing it etc. even when not doing any non-trivial substitutions. Honza > > > r~
is pr26565 broken again?
On s390x it produces this insn:
(insn 8 7 9 3 323444.c:15 (set (mem/s:DI (reg:DI 46) [0 S8 A64])
(mem/s:DI (reg/v/f:DI 45 [ tp ]) [0 S8 A64])) -1 (nil))
Note that the alignments are 64 bit again, despite the field being
packed. mep-elf has similar results.
void *memcpy(void *dest, const void *src, __SIZE_TYPE__ n);
struct timeval {
long tv_sec;
};
struct outdata {
long align;
char seq;
struct timeval tv __attribute__((packed));
};
void send_probe(struct outdata *outdata, struct timeval *tp)
{
memcpy(&(outdata->tv), tp, sizeof outdata->tv);
}
send_probe (struct outdata * outdata, struct timeval * tp)
{
struct timeval * D.1971;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1971_2 = &outdata_1(D)->tv;
memcpy (D.1971_2, tp_3(D), 8); [tail call]
return;
# SUCC: EXIT [100.0%]
}
Re: [trans-mem] cgraph edges vs function cloning
On 07/28/2009 10:44 AM, Richard Henderson wrote: I guess I'll poke at cleaning this up today. I've got to familiarize myself with how virtual clones work... The virtual clones that ipa-cp makes seems to be easy. My thought here is that since (virtual) clones don't have actual bodies (and when they acquire bodies they cease to be clones), then there's no reason for them to have callee edges at all. If you want the list of callees for a clone, you look at node->clone_of->callees. In this way, when we materialize a clone, we don't have to go looking for (and updating) edges, we just create them as we copy the statements. What I don't understand is how the inliner uses clones. Can you explain this? r~
gcc-4.4-20090728 is now available
Snapshot gcc-4.4-20090728 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090728/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 150188 You'll find: gcc-4.4-20090728.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090728.tar.bz2 C front end and core compiler gcc-ada-4.4-20090728.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090728.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090728.tar.bz2 C++ front end and runtime gcc-java-4.4-20090728.tar.bz2 Java front end and runtime gcc-objc-4.4-20090728.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090728.tar.bz2The GCC testsuite Diffs from 4.4-20090721 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Re: The future of concepts
2009/7/28 Basile STARYNKEVITCH: > > It could perhaps be not a branch, but a plugin, but I know not much about > C++ concepts, and absolutely nothing about the existing C++ concepts > branch[es]. I don't think that would work - the standard library changes that go along with the language feature could not be implemented as a plugin. A branch seems like the right way to do it. Jonathan
Call for papers: 2nd Workshop on GCC Research Opportunities (GROW '10)
Apologies if you receive multiple copies of this call. CALL FOR PAPERS 2nd Workshop on GCC Research Opportunities (GROW '10) http://ctuning.org/workshop-grow10 January 23, 2010, Pisa, Italy (co-located with HiPEAC 2010 Conference) GROW workshop focuses on current challenges in research and development of compiler analyses and optimizations based on the free GNU Compiler Collection (GCC). The goal of this workshop is to bring together people from industry and academia that are interested in conducting research based on GCC and enhancing this compiler suite for research needs. The workshop will promote and disseminate compiler research (recent, ongoing or planned) with GCC, as a robust industrial-strength vehicle that supports free and collaborative research. The program will include an invited talk and a discussion panel on future research and development directions of GCC. Topics of interest Any issue related to innovative program analysis, optimizations and run-time adaptation with GCC including but not limited to: * Classical compiler analyses, transformations and optimizations * Power-aware analyses and optimizations * Language/Compiler/HW cooperation * Optimizing compilation tools for heterogeneous/reconfigurable/ multicore systems * Tools to improve compiler configurability and retargetability * Profiling, program instrumentation and dynamic analysis * Iterative and collective feedback-directed optimization * Case studies and performance evaluations * Techniques and tools to improve usability and quality of GCC * Plugins to enhance research capabilities of GCC Paper Submission Guidelines Submitted papers should be original and not published or submitted for publication elsewhere; papers similar to published or submitted work must include an explicit explanation. Papers should use the LNCS format and should be 12 pages maximum. Please, submit via the easychair system at the GROW'10 website. Papers will be refereed by the Program Committee and if accepted, and if the authors wish, will be made available on the workshop web site. Authors of the best papers from the workshop may be invited to revise their submission for the journal "Transactions on HiPEAC", if the work is in sufficiently mature form. Important Dates Deadline for submission: November 13, 2009 Decision notification: December 14, 2009 Workshop: January 23, 2010 half-day Organizers , Grigori Fursin, INRIA, France Dorit Nuzman, IBM, Israel Program Committee Arutyun I. Avetisyan, ISP RAS, Russia Zbigniew Chamski, Infrasoft IT Solutions, Poland Albert Cohen, INRIA, France David Edelsohn, IBM, USA Bjorn Franke, University of Edinburgh, UK Grigori Fursin, INRIA, France Benedict Gaster, AMD, USA Jan Hubicka, SUSE Paul H.J. Kelly, Imperial College of London, UK Ondrej Lhotak, University of Waterloo, Canada Hans-Peter Nilsson, Axis Communications, Sweden Diego Novillo, Google, Canada Dorit Nuzman, IBM, Israel Sebastian Pop, AMD, USA Ian Lance Taylor, Google, USA Chengyong Wu, ICT, China, Kenneth Zadeck, NaturalBridge, USA Ayal Zaks, IBM, Israel Keynote talk Diego Novillo, Google, Canada, "Using GCC as a toolbox for research: GCC plugins and whole-program compilation" Previous Workshops GROW'09: http://www.doc.ic.ac.uk/~phjk/GROW09 GREPS'07: http://sysrun.haifa.il.ibm.com/hrl/greps2007
Re: [trans-mem] cgraph edges vs function cloning
On 07/28/2009 10:16 AM, Jan Hubicka wrote: There is code in cgraph_copy_node_for_versioning that redirect callers in the list to new location. Since clonning might render some code unreachable and remove edges, this can lead to ICE. But since this was formely invented for IPA-CP, that is now using virtual clones, perhaps we can simply drop this functionality unless you need it in your branch? I need nothing complicated from cgraph. An exact duplicate of the original function is perfect. After getting that duplicate, I'll walk through it and make some localized code changes which are just a tad more complicated than simple symbol substitution. After optimization is where the bulk (but not all) of the changes for TM are applied. I guess I'll poke at cleaning this up today. I've got to familiarize myself with how virtual clones work... r~
Re: [trans-mem] cgraph edges vs function cloning
> > struct cgraph_edge *edge = cgraph_edge (id->src_node,
> > orig_stmt);
> POINT_A
> > int flags;
> >
> > switch (id->transform_call_graph_edges)
> >{
> > case CB_CGE_DUPLICATE:
> >if (edge)
> > cgraph_clone_edge (edge, id->dst_node, stmt,
> > REG_BR_PROB_BASE, 1,
> > edge->frequency, true);
> >break;
> >
> > case CB_CGE_MOVE_CLONES:
> >cgraph_set_call_stmt_including_clones (id->dst_node,
> >orig_stmt, stmt);
> >break;
> >
> > case CB_CGE_MOVE:
> >if (edge)
> > cgraph_set_call_stmt (edge, stmt);
> POINT_B
> >break;
> >
> > default:
> >gcc_unreachable ();
> >}
> >
> >edge = cgraph_edge (id->src_node, orig_stmt);
> POINT_C
> >/* Constant propagation on argument done during inlining
> > may create new direct call. Produce an edge for it. */
> >if ((!edge
> > || (edge->indirect_call
> > && id->transform_call_graph_edges ==
> > CB_CGE_MOVE_CLONES))
> >&& is_gimple_call (stmt)
> >&& (fn = gimple_call_fndecl (stmt)) != NULL)
> POINT_D
>
> This code cannot possibly work.
>
> We begin by looking up the edge at POINT_A.
> We then move the edge at POINT_B.
> We then look up the edge *again* at POINT_C.
> Ought we be surprised when we do not find the edge at POINT_D?
>
> After POINT_D, we "fix" the missing edge by creating a new one, which of
> course is a duplicate, which then of course leads to verification failure.
>
> I think POINT_B is additionally buggy in that we've just corrupted
> the cgraph node for the source function when we wanted to change the
> destination function. I believe we should have done
>
> case CB_CGE_MOVE:
> edge = cgraph_edge (id->dst_node, orig_stmt);
> cgraph_set_call_stmt (edge, stmt);
> // Possibly fix up indirect->direct call here.
Yes, this looks fine. It looks like bug I formery introduced when
moving code for new clones.
>
> Although, frankly I think it would be easiest to *only* create edges
> here. There ought to be no problem doing the cgraph_clone_edge here
> instead of in cgraph_copy_node_for_versioning. That would still
> preserve all of the information you wanted that's attached to the edges.
>
> Thoughts?
There is code in cgraph_copy_node_for_versioning that redirect callers
in the list to new location. Since clonning might render some code
unreachable and remove edges, this can lead to ICE. But since this
was formely invented for IPA-CP, that is now using virtual clones,
perhaps we can simply drop this functionality unless you need it in your
branch?
Honza
>
>
> r~
Re: The future of concepts
Ed Smith-Rowland wrote:
James Dennett wrote:
On Tue, Jul 28, 2009 at 3:01 AM, Piotr
Wyderski wrote:
Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?
I hope not. Concepts will be "finished" and re-added to C++, and it
would be immensely helpful in that effort if there were a version of
g++ with stronger Concepts support than ConceptGCC had.
-- James
We need a gcc branch for concepts. One of the major complaints on
concepts and one of the major contributors to its being dropped is that
there is no implementation experience.
It could perhaps be not a branch, but a plugin, but I know not much
about C++ concepts, and absolutely nothing about the existing C++
concepts branch[es].
My belief is that making such code a plugin and not a branch would make
both the plugin feature and the experimental language feature (concepts)
more popular. And perhaps maintaining a plugin could mean less work than
maintaing an entire branch.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: How to figure out the gcc -dP output?
On Tue, Jul 28, 2009 at 10:44 AM, Tim Crook wrote: > Thanks David. > > I thought -mmininal-toc might have been a better workaround as well :-) . > > Is there a Bugzilla number for this issue? I believe this was GCC Bugzilla Bug 24779. It partially was fixed in GCC 4.1, but not fully fixed until December 2008. David
Re: The future of concepts
James Dennett wrote: On Tue, Jul 28, 2009 at 3:01 AM, Piotr Wyderski wrote: Concepts have recently been removed from the C++0x Standard Draft. Will the concepts branch be discontinued? I hope not. Concepts will be "finished" and re-added to C++, and it would be immensely helpful in that effort if there were a version of g++ with stronger Concepts support than ConceptGCC had. -- James We need a gcc branch for concepts. One of the major complaints on concepts and one of the major contributors to its being dropped is that there is no implementation experience. There was no implementation of sufficient quality and availability to give compiler developers confidence and point to wrinkles in the definition and users time to learn and play. It will take a good couple of years to get one working. That leaves open the question of whether the ConceptGCC branch is the one. I just don't know. Maybe someone should start over. I think aim for simplicity. That was another issue I think: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2906.pdf (Stroustrup) Ed
RE: How to figure out the gcc -dP output?
Thanks David. I thought -mmininal-toc might have been a better workaround as well :-) . Is there a Bugzilla number for this issue? -Original Message- From: David Edelsohn [mailto:dje@gmail.com] Sent: Tuesday, July 28, 2009 9:46 AM To: Tim Crook Subject: Re: How to figure out the gcc -dP output? Tim, I do not fully understand the complete explanation of the original problem. You mention extraneous lwz and TOC. I think you are referring to a bug in GCC 4.1 that incorrectly emitted loads after the TOC already had been changed for an indirect call. GCSE probably is producing code that requires a constant and GCC needs to place that constant in the TOC. The late creation of the TOC reference is not scheduled correctly. GCSE is an optimization. -mminimal-toc is an option to avoid TOC overflow. Both of these are work-arounds to the problem. Disabling GCSE probably will slow down the application. -mminimal-toc probably will have less of a performance impact. As I mentioned to Chris when I spoke with him last week, I would recomment upgrading to a newer version of GCC because GCC 4.1 no longer is maintained. Many bug fixes, such as one for the problem you are encountering, are incorporated into newer releases. David > I found a possible compiler workaround, compiling with -mminimal-toc. Would > I get better performance by using this, instead of turning off gcse? On Fri, Jul 24, 2009 at 4:34 PM, Tim Crook wrote: > Hello there. > > I am trying to track down a problem with gcc 4.1 which has to do with > inlining and templates on PowerPC. Is there any documentation I can look > related to the output generated with -fdump? I am getting extraneous lwz > (load word and zero extend) instructions inserted when calling various > methods - after $toc (r2) has been switched to the destination method's > global data, just before the method call with the bctrl instruction. This lwz > instruction causes a crash on IBM AIX when 32-bit shared libraries are loaded > non-contiguously in memory. It looks like various code blocks are not being > combined correctly when code is inlined - the extra lwz is being left behind. > > I have figured out that turning off gcse optimizations will stop this > behavior, but doing this causes a performance hit. I would prefer not to > upgrade the compiler at this time. With the compiler dump using -fdump, I am > looking for a better way to work around this problem. > > Tim Crook. >
Re: The future of concepts
On Tue, Jul 28, 2009 at 3:01 AM, Piotr Wyderski wrote: > Concepts have recently been removed from the C++0x Standard Draft. > Will the concepts branch be discontinued? I hope not. Concepts will be "finished" and re-added to C++, and it would be immensely helpful in that effort if there were a version of g++ with stronger Concepts support than ConceptGCC had. -- James
The future of concepts
Concepts have recently been removed from the C++0x Standard Draft. Will the concepts branch be discontinued?
Cannot configure gcc4.4.0 in order to build h8300 crosscompiler
Hello everyone, I am struggling to build h8300 crosscompiler from GCC4.4.0. I learned it is necessary to patch gcc for complying to double 64 bits. I used next sources. binutils-2.19.1.tar.bz2 gcc-4.4.0.tar.bz2 newlib-1.17.0.tar.gz I've got patch for GCC3.3.2 source. I appended it in compressed file. patch-sources/patch-for-gcc3.3.2/gcc_diff-new.txt But I was disappointed that it could not be used for GCC4.4.0 source per se. So I studied the patch and converted GCC4.4.0 source for installing h8300 croscompiler. The patch changes next four files. /gcc-3.3.2/gcc/config/h8300/extfloatlib.c /gcc-3.3.2/gcc/config/h8300/float-h8300.h /gcc-3.3.2/gcc/config/h8300/h8300.h /gcc-3.3.2/gcc/config/h8300/t-h8300 First two files(extfloatlib.c,float-h8300.h) are newly made,so I think I could use them per ce into GCC4.4.0 source. h8300.h and t-h8300 are modified and I must apply differences to GCC4.4.0 source. I appended gcc3.3.2 original h8300.h,t-h8300. patch-sources/gcc3.3.2-before-patch-sources/h8300.h,t-h8300 And after-patch-applied gcc3.3.2 four files. patch-sources/gcc3.3.2-after-patch-sources/h8300.h,t-h8300,extfloatlib.c,float-h8300.h And gcc4.4.0 original h8300.h,t-h8300. patch-sources\gcc4.4.0-original-sources/h8300.h,t-h8300 And after-patch-converted gcc4.4.0 four files. patch-sources/gcc4.4.0-patch-converted-sources/h8300.h,t-h8300,extfloatlib.c,float-h8300.h I succeeded binutils configure. But when I configured gcc next error happened. --error /tmp/build/build_gcc/./gcc/xgcc -B/tmp/build/build_gcc/./gcc/ -nostdinc -B/tmp/build/build_gcc/h8300-elf/newlib/ -isyste m /tmp/build/build_gcc/h8300-elf/newlib/targ-include -isystem /src/gcc-4.4.0/newlib/libc/include -B/gnutools/h8300-elf/b in/ -B/gnutools/h8300-elf/lib/ -isystem /gnutools/h8300-elf/include -isystem /gnutools/h8300-elf/sys-include -g -O2 -mh -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wca st-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. - I../../.././gcc -I/src/gcc-4.4.0/libgcc -I/src/gcc-4.4.0/libgcc/. -I/src/gcc-4.4.0/libgcc/../gcc -I/src/gcc-4.4.0/libgcc /../include -DHAVE_CC_TLS -o _bswapdi2.o -MT _bswapdi2.o -MD -MP -MF _bswapdi2.dep -DL_bswapdi2 -c /src/gcc-4.4.0/libgc c/../gcc/libgcc2.c \ /src/gcc-4.4.0/libgcc/../gcc/libgcc2.c:503: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__bswapdi2' /src/gcc-4.4.0/libgcc/../gcc/libgcc2.c:505:19: warning: integer constant is too large for its type /src/gcc-4.4.0/libgcc/../gcc/libgcc2.c:506:14: warning: integer constant is too large for its type /src/gcc-4.4.0/libgcc/../gcc/libgcc2.c:507:14: warning: integer constant is too large for its type /src/gcc-4.4.0/libgcc/../gcc/libgcc2.c:508:14: warning: integer constant is too large for its type make[4]: *** [_bswapdi2.o] Error 1 make[4]: Leaving directory `/tmp/build/build_gcc/h8300-elf/h8300h/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/tmp/build/build_gcc/h8300-elf/libgcc' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/tmp/build/build_gcc/h8300-elf/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/build/build_gcc' make: *** [all] Error 2 make: Leaving directory `/tmp/build/build_gcc' -- end of error It is caused by next declaration in libgcc2.c. #ifdef L_bswapdi2 DItype __bswapdi2 (DItype u) Since when I retrieved original h8300.h,t-h8300 then not occurred above error, I am sure I wrongly converted gcc4.4.0 four files. Would you please teach me what is wrong my conversion ? Please help me. Masahiro Ariga patch-sources.tar.bz2 Description: Binary data
