This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Superblock Instruction Scheduling in GCC


> 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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]