This is the mail archive of the 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]

Re: basic-block and profile-based optimizing (was Re: New attribute "infrequent"?)

> > I don't think that adding such an attribute-mechanism to a library
> > interface is all that necessary, nor will it be worth the work and
> > maintance.
> I strongly agree.
> I think that sometimes we try to invent new techinques for
> dealing with old problems.  The cold hard reality of the situation is
> that people have been building compilers that often generate better
> code than GCC for quite a while without using anything similar
> to this attribute, to the best of my knowledge.
> That doesn't mean we shouldn't add it, necessary -- perhaps we are
> cleverer than other implementors, or have found a new and different
> way to solve a problem -- but I believe that generally we are better
> off imitating best existing practice.  If Sun, HP, IBM, and Intel
> can all get by without it, and still generate good code, then
> probably we can too.
> Do any other compiler vendors have such an attribute?
There are few papers and vendor compilers implementing such attribute (at least
my odish HP compiler do have it), but I tend to agree with your opinion now
too. The fact that I've asked on list before implementing was than I wasn't
sure about effectivity of such feature and the discussion seems to result that
it most probably isn't. There are other thinks I want invest my energy into.

On the other hand, I don't think we should have just features supported
by other compiler vendors. Gcc do have some unique extensions and not
all of them are pure scrap.

Making gcc monotone subset of features provided by vendor compilers won't let
us survive.

> -- 
> Mark Mitchell      
> CodeSourcery, LLC  

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