This is the mail archive of the gcc@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: gcc compile-time statistics


> On Wed, May 22, 2002 at 12:47:47AM -0700, David S. Miller wrote:
> >    From: Geoff Keating <geoffk@geoffk.org>
> >    Date: 18 May 2002 19:06:13 -0700
> >    
> >    I looked at the reason for the slowdown, and it seems likely the
> >    reason for the slowdown between 3.0.4 and 3.1 at -O0 on x86 is more
> >    complex RTL.  Not more insns (in fact, fewer insns), but more
> >    complexity within each insn.  Reload is taking twice as long to handle
> >    fewer insns, ggc_alloc is called 30% more times, and so on.
> > 
> > Note my other posting today wrt. N_REGISTER_CLASSES.
> > 
> > On x86 from 3.0.x to 3.1 this went up from 19 to 25
> > That does account for the increase in reload
> > and regclass time.
> 
> What are e.g. FP_TOP_SSE_REGS and FP_SECOND_SSE_REGS classes good for?
> Are they there just for completeness? There is no class for union of DREG
> and SIREG either for example.

These may come out as preffered or alternate class from regclass computations,
where costs from multiple instructions (one requiring top register, one
SSE) combine together.
Removing them made code measurably worse :(
Basically the classes should be closed for union and intersection, but
for i386 this runs out of control, so just few "important" are
sellected.

Honza
> I see no .md pattern which would accept either %st (resp %st(1)) or an SSE
> register and cannot imagine somebody would write such assembly.
> 
> 	Jakub


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