Related articles |
---|
Death by error checks. ianr@lsl.co.uk (1995-11-21) |
Death by error checks. dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-27) |
Re: Death by error checks. jgj@ssd.hcsc.com (1995-11-28) |
Re: Death by error checks. sethml@dice.ugcs.caltech.edu (1995-11-28) |
Re: Death by error checks. Terry_Madsen@mindlink.bc.ca (1995-11-30) |
Re: Death by error checks. cliffc@ami.sps.mot.com (1995-11-30) |
Re: Death by error checks. sethml@avarice.ugcs.caltech.edu (1995-12-09) |
Re: Death by error checks. veeru@hpclearf.cup.hp.com (Veeru Mehta) (1995-12-17) |
Re: Death by error checks. hbaker@netcom.com (1995-12-19) |
Newsgroups: | comp.compilers |
From: | jgj@ssd.hcsc.com (Jeff Jackson) |
Keywords: | errors, optimize |
Organization: | I would rather be windsurfing. |
References: | 95-11-183 |
Date: | Tue, 28 Nov 1995 15:02:53 GMT |
> status = f(....);
> if (status != NORMAL)
> {
> /* stack error message include file name and line number */
> return status;
> }
> What I would like to do, is give the 'c' compiler a hint in the
> macro, that the 'if' should be predicted not taken.
Harris Computer Systems' compiler would need no hint. A guard test on
a return is assumped to be testing for an exceptional condition and so
would assume to path to return is not normally taken. This is used to
set the static prediction bit in the instruction and also to guide
global instruction scheduling (though your if-body probably has no
instructions to speculatively schedule, our compiler would try to
speculatively schedule instructions from the predicted-taken side
before it would the predicted-not-taken side of the if if there were
any to schedule). Someday, I would like to use such static
predictions to guide profitability analysis of other optimizations
such as partial redundancy.
--
===========================================================================
Jeffrey Glen Jackson
jgj@ssd.csd.harris.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.