I could not check out the integrated patch since the cvs server is currently down. On the other hand, when I tried to add the patch (as published on the web) manually on top of release 3.3.1 the resulting binary failed. I am not sure if I did something wrong or just needed to do that on top of a more recent version of the gcc code. So, I am kind of stuck at this point. Do you have any source files that I can add on top of release 3.3.1 or 3.3.2 to enable superblock scheduling? Thanks -Ghassan On Thu, 4 Dec 2003, Jan Hubicka wrote: > > Ghassan Shobaki wrote: > > > > > I know how to get gcc to form superblocks (by using the -ftracer > > > command-line switch), but is there a way to get it to use these > > > superblocks as scheduling regions in the instruction scheduling pass? > > > Currently, the instruction scheduling module forms regions that are totally > > > different from the superblocks that are formed in the tracer module > > > even though each superblock is a valid scheduling region. > > > Any idea how I can achieve this? Or are there any plans to do superblock > > > instruction scheduling in the near future? > > > > There was Jan Hubicka's patch for this. Please look at it > > > > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00499.html > > > > This patch should work for all platforms except for IA64 whose the second > > scheduling is made on EBB. > > This patch is currently in the mainline tree, so you can simply use > -fsched2-use-traces / -fsched2-use-superblocks > > > > I tried trace scheduling for IA64 (but I did not post the patch for ia64). > > Here the results are > > > > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00499.html > > > > The problem with trace scheduling is that the generated code is bigger, the > > compiler is slower and the code improvement is insignificant. > > > > If you manage to achieve an improvement for a platform on a credible > > benchmark (SPEC95, SPEC2000), we could consider to add the patch to gcc at > > least for given platform for -O3. Because the compiler changed since the > > patch was posted, there is a probability that you could achieve this. > > Yes, we need experimenting here. > I was quite surprised that the benefits wasn't too noticeable on > in-order architecture and I would like to hear about any results > (positive or negative). > -fsched2-use-superblocks should bring most of benefits at no code size > costs, while -fsched2-use-traces is more experimental and probably needs > profile feedback to do somethign usefull. (I managed to get some > speedups using this on Athlon but the benefits wasn't considerable > enought to discuss inclusion in -O3 -fbranch-probabilities combination) > > Honza > > > > > > Vlad > > >
