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) |
[1 later articles] |
Newsgroups: | comp.compilers |
From: | Dave Lloyd <dave@occl-cam.demon.co.uk> |
Keywords: | C, errors, optimize |
Organization: | Compilers Central |
References: | 95-11-183 |
Date: | Mon, 27 Nov 1995 13:16:21 GMT |
> What I would like to do, is give the 'c' compiler a hint in the
> macro, that the 'if' should be predicted not taken. Are there any
This will only help on processors with directable static branch
prediction. What would be more useful is for the compiler to move
the body of the if clause out of line which will improve cache/page
coherence and the default case will just be a skip of the conditional
branch. If it wasn't for the macro you could do this manually with
fair chance of success by explicit jumps and hope the compiler
optimises an if clause containing a single branch to a conditional
branch. There are tools which attempt to do this sort of thing at the
link level based on run-time stats (e.g., LXOPT under OS/2).
Regards,
----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.