Ricardo B (ricardo.b.delete@this.xxxxx.xx) on August 19, 2012 7:26 pm wrote:
> anon (anon.delete@this.anon.com) on August 19, 2012 6:07 pm wrote:
> > Ricardo
> B (ricardo.b.delete@this.xxxxx.xx) on August 19, 2012 11:02 am
> >
> wrote:
> > > anon (anon.delete@this.anon.com) on August 18, 2012 2:23 am
>
> > wrote:
> > > >
> > > >
> > > So it could certainly
> do a lot better. I
> >
> > > > suspect a really aggressive and
>
> > > smart whole program optimizer
> > and register
> > > >
> allocator could take
> > > significantly more
> > advantage of large
> register counts, but
> > > > perhaps these
> > > kinds
> > of
> optimizations are just too expensive with current
> > > >
> > >
>
> > technology.
> > >
> > > I think the improvements will be
> marginal, *specially*
> > with
> > > larger register counts.
> >
>
> > We're talking about compiler making
> > better use of more registers,
> so improvement should be larger with more
> > registers available.
> >
>
> > > A proper caller-saved/callee-saved convention
> > already
> >
> > provides the majority of the benefit.
> > > And if it's case
> >
> where it matters... it's
> > > probably a case for inlining the
> callee.
> >
> > I
> > think those are two independent concerns. Inlining
> is already done. And you
> > don't necessarily want to do it if it results in
> code bloat.
>
> I was referring to the need of a dynamic calling
> convention.
>
> Typically, compilers will use all registers available to
> them.

No, not with, for example unix or microsoft x86-64 calling convention.

> The overhead of a static calling convention is that you'll get some
> spills to memory that could have been avoided by a dynamic calling convention
> generated by a inter-function analysis.

It is more than just these spills. Also lose aliasing information, knowledge of global memory modification and register clobbers, have to go to memory when returning more than 64 bits, probably have to shuffle values around registers etc. All of these things basically shorten the useful life of values in registers so they will hinder optimal use of a large number of registers.


>
> My reasoning is that if the overhead
> of those spills impacts performance, then we're usually dealing with small
> functions which are called often -- good candidates for inlining.
>

Sometimes yes, sometimes no. If they are called from many places, or are not leaf functions, then they may not be good candidates for inlining even if small.