From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jan Hubicka Cc: rth@cygnus.com, gcc@gcc.gnu.org Subject: Re: speeding up liveness analysis ideas. Date: Sat, 20 Oct 2001 09:06:00 -0000 Message-id: <5FCDB177-C574-11D5-8FCC-0030657B5340@cgsoftware.com> References: <20011020132333.B11355@atrey.karlin.mff.cuni.cz> X-SW-Source: 2001-10/msg01097.html On Saturday, October 20, 2001, at 07:23 AM, Jan Hubicka wrote: > Hi, > Not only on Brad's testcase we spend very important amount of time in > the > liveness analysis. This is relatively sad score and I think we should > try > to improve it. It is also interesting that the times appears to be > considerably > worse in the current code than they was in 3.0 times and I don't recall > any > important change to the code possibly responsible for that. > > It could just be bad bitmap set/clear ordering or something. In fact, it's likely the cause if you are correct in that there have been few changes to the code. Just changing the number/spread across blocks of registers would have a significant impact on the speed of the bitmap operations. Once they fall out of the current bitmap element, it's linear. > Here are several assorted ideas what I think can help > > 1) Use df.c module to find the references and uses - we currently spend > quite a lot of time in mark_set_1 and for_each_rtx modules. > Discovering all > uses/sets at once before relaxation process can be good idea... Yup. > 2) Reverse topological order the blocks for relaxation progress > - this should help any iterative dataflow.. Yup.