Re: Inline Expansion Problem
On Sun, Aug 28, 2011 at 1:30 AM, Matt Davis wrote: > On Sat, Aug 27, 2011 at 11:25:45AM +0200, Richard Guenther wrote: >> On Sat, Aug 27, 2011 at 10:06 AM, Matt Davis wrote: >> > On Sat, Aug 27, 2011 at 09:27:49AM +0200, Richard Guenther wrote: >> >> On Sat, Aug 27, 2011 at 4:47 AM, Matt Davis wrote: >> >> > Hello, >> >> > I am having the compiler insert a call to a function which is defined >> >> > inside >> >> > another object file. However, during inline expansion via >> >> > expand_call_inline(), >> >> > the following assertion fails in tree-inline.c: >> >> >>> 3775: edge = cgraph_edge (id->dst_node, stmt); >> >> >>> 3776: gcc_checking_assert (cg_edge); >> >> > >> >> > cg_node comes back as being NULL since there is only one callee and no >> >> > indirect >> >> > calls, the function that has the inserted call is main(). Is there >> >> > something I >> >> > forgot to do after inserting the gimple call statement? This works >> >> > fine without >> >> > optimization. >> >> >> >> Dependent on where you do it you have to add/rebuild cgraph edges. >> > >> > Thanks Richard, >> > I tired "rebuild_cgraph_edges()" before I sent the initial email. >> > Unfortunately, when I call that function after I add the statement, in an >> > IPA >> > pass, the resulting binary does not link, as it does not seem able to >> > resolve >> > the symbol to the callee. Maybe providing more context would help make >> > more >> > sense. insert_func_call inserts the call by adding a new gimple call >> > statement. >> > I've done this tons of times before, but it seems with -O the callgraph >> > isn't >> > happy. >> >> If you are doing this from an IPA pass you have to add the edge manually >> using >> update_edges_for_call_stmt. > > Thanks Richard, > I was unable to properly use update_edges_for_call_stmt. It seems that > routine > is for updating an existing call. In my case I am inserting a new gimple call > via gsi_insert_before() with GSI_NEW_STMT. As a gimple pass, this works fine. > I appreciate all of your correspondence. Well, from looking at the function it should work if you pass NULL as the old stmt. If it does not, figure out why. Richard. > -Matt >
performance regression with trunk's gengtype on ARM?
I'm seeing what appears to be a recent massive performance regression with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE. Right now 4.7-20110827's stage2 gengtype has been running for almost 10 hours on my ARM build machine, but the process is tiny and no swapping occurs. To put those 10 hours in perspective, on this machine (1.6 GHz ARM V5TE uniprocessor running Linux) I regularly do full bootstraps and regression test suite runs for c,c++,ada,fortran in about 18 hours for gcc 4.4, about 20 hours for gcc 4.5, about 24 hours for gcc 4.6, and about 27 hours for trunk until recently. So 10 hours or more just in stage 2 gengtype is suspicious. I believe 4.7-20110820 also was unusually slow to build, but I didn't monitor that build very carefully so can't say if gengtype was involved then too. /Mikael
Re: performance regression with trunk's gengtype on ARM?
On Mon, Aug 29, 2011 at 8:57 AM, Mikael Pettersson wrote: > I'm seeing what appears to be a recent massive performance regression > with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE. > > Right now 4.7-20110827's stage2 gengtype has been running for almost > 10 hours on my ARM build machine, but the process is tiny and no swapping > occurs. To put those 10 hours in perspective, on this machine (1.6 GHz > ARM V5TE uniprocessor running Linux) I regularly do full bootstraps and > regression test suite runs for c,c++,ada,fortran in about 18 hours for > gcc 4.4, about 20 hours for gcc 4.5, about 24 hours for gcc 4.6, and > about 27 hours for trunk until recently. So 10 hours or more just in > stage 2 gengtype is suspicious. > > I believe 4.7-20110820 also was unusually slow to build, but I didn't > monitor that build very carefully so can't say if gengtype was involved > then too. FWIW, I build trunk once a week on a PandaBoard. r178096 took 10 hours to bootstrap C, C++, and Fortran and 9 hours to test. The 4.5 release branch at r177893 takes 3:50 to bootstrap and 6:15 to test. I've put the user time in seconds below. 4.5 is ~2 s, 4.6 is ~23000 s, and current trunk ~46000 (2.3 x slower). See http://builds.linaro.org/toolchain/ for more. -- Michael gcc-4.5+svn175369 20602.07 gcc-4.5+svn175745 19768.21 gcc-4.5+svn176026 19739.35 gcc-4.5+svn176306 19711.70 gcc-4.5+svn176615 19668.38 gcc-4.5+svn176915 19728.38 gcc-4.5+svn177422 19713.14 gcc-4.5+svn177688 19746.67 gcc-4.5+svn177893 19744.96 gcc-4.6+svn175136 22979.51 gcc-4.6+svn175369 23092.50 gcc-4.6+svn175745 22958.21 gcc-4.6+svn176026 23009.37 gcc-4.6+svn176306 22952.93 gcc-4.6+svn176615 22952.11 gcc-4.6+svn177422 22946.22 gcc-4.6+svn177688 22847.87 gcc-4.6+svn177894 22964.09 gcc-4.6+svn178096 22934.61 gcc-4.7~svn175284 34518.10 gcc-4.7~svn175368 34887.17 gcc-4.7~svn175422 34975.48 gcc-4.7~svn175617 34908.60 gcc-4.7~svn175745 35040.42 gcc-4.7~svn175795 35110.84 gcc-4.7~svn175904 34893.29 gcc-4.7~svn176026 34972.99 gcc-4.7~svn176133 35171.65 gcc-4.7~svn176224 35247.44 gcc-4.7~svn176306 35038.07 gcc-4.7~svn176494 26151.21 gcc-4.7~svn176615 26257.04 gcc-4.7~svn176733 40401.18 gcc-4.7~svn176816 40048.32 gcc-4.7~svn176915 40102.52 gcc-4.7~svn176998 40161.10 gcc-4.7~svn177229 28604.27 gcc-4.7~svn177422 44991.89 gcc-4.7~svn177554 45199.05 gcc-4.7~svn177610 45173.94 gcc-4.7~svn177688 45469.00 gcc-4.7~svn177823 45391.00 gcc-4.7~svn177949 28769.64 gcc-4.7~svn178025 45605.43 gcc-4.7~svn178096 45599.59
Re: ARM summit at Plumbers 2011
On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote: > UPDATE: we've not had many people confirm interest in this event yet, > which is a shame. If you would like to join us for this session, > please reply and let me know. If we don't get enough interest by the > end of Sunday (28th August), then we'll have to cancel the meeting. I'm obviously confirming, but I'll repeat that for the record. My interests here include helping to lead up Fedora's ARMv7 efforts, but also wider ARM platform standardization (boot, device enumeration, multi-arch, ABI, kernel consolidation, and many other things). If there's at least representation from a few of the distros (as it seems is the case at this point) then I think it's worthwhile having the formal slots. Nothing is lost in so doing. In any case, many discussions will take place if we have the opportunity to do so. Jon.
Re: performance regression with trunk's gengtype on ARM?
On Sun, 28 Aug 2011 22:57:54 +0200
Mikael Pettersson wrote:
> I'm seeing what appears to be a recent massive performance regression
> with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE.
>
> Right now 4.7-20110827's stage2 gengtype has been running for almost
> 10 hours on my ARM build machine, but the process is tiny and no swapping
> occurs. [...]
This is indeed very suspicious (especially since it happens in stage2, not in
stage1,
IIUY). Can you ltrace or strace the gengtype process?
You could set GENGTYPE_FLAGS= -v in gcc/Makefile.in to understand more what
gengtype is
doing. And gengtype accepts several -v flags.
Cheers.
--
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 mine, sont seulement les miennes} ***
