Re: static estimation of conditional branches?

glew@pdx007.intel.com (Andy Glew)
Sat, 12 Dec 1992 23:37:37 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Re: static estimation of conditional branches? bill@amber.csd.harris.com (1992-12-10)
Re: static estimation of conditional branches? hrubin@pop.stat.purdue.edu (1992-12-11)
Re: static estimation of conditional branches? henry@zoo.toronto.edu (1992-12-11)
Re: static estimation of conditional branches? idacrd!desj@uunet.UU.NET (1992-12-12)
Re: static estimation of conditional branches? jfisher@hplabsz.hpl.hp.com (1992-12-11)
Re: static estimation of conditional branches? chased@rbbb.Eng.Sun.COM (1992-12-12)
Re: static estimation of conditional branches? glew@pdx007.intel.com (1992-12-12)
Re: static estimation of conditional branches? henry@zoo.toronto.edu (1992-12-13)
Re: static estimation of conditional branches? hrubin@pop.stat.purdue.edu (1992-12-13)
Re: static estimation of conditional branches? drw@euclid.mit.edu (1992-12-14)
Re: static estimation of conditional branches? idacrd!desj@uunet.UU.NET (1992-12-14)
Re: static estimation of conditional branches? iwm@doc.ic.ac.uk (1992-12-14)
Re: static estimation of conditional branches? pcg@aber.ac.uk (1992-12-15)
| List of all articles for this month |
Newsgroups: comp.compilers
From: glew@pdx007.intel.com (Andy Glew)
Organization: Intel Corp., Hillsboro, Oregon
Date: Sat, 12 Dec 1992 23:37:37 GMT
References: 92-12-029 92-12-037
Keywords: optimize

> I surmised that the original poster was asking if there was any empirical
> data to say that "most if-tests are taken" or "most if-tests are not
> taken". However, I would think that such conclusions would be heavily
> influenced by programming style and the programmer's personal preferences.


This does suggest a heuristic such as the following:


If one side of a conditional contains exit(nonzero), the word "error", or
an fprintf(stderr,...) or perror(), predict that side of the conditional
not to be taken.


Sure, it's dirty. But it's better than annotating with a #pragma. And
it's the sort of thing human programmers do all the time.
--
Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy,
Hillsboro, Oregon 97124-6497
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.