> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka <[email protected]> wrote: > >> Actually Dehao also plans to teach the static predictor to understand > >> standard library functions more (e.g IO functions) and add more naming > > > > How this differ from annotating the library? > > I find them more suitable to be compiler heuristic than being > function's attribute -- attribute is a much stronger assertion.
Why so? Special matching the function names in compiler is pretty much the same thing as annotating them in the source, right? > > > > > There are indeed quite some possibilities to do about library calls.... > > > > One thing I always wondered about is how to tell predictor that paths > > containing > > heavy IO functions don't need to be really opimized to death, since their > > execution > > time is dominated by the IO... > > > > Yes -- if branch predictor does the right thing and if function > splitter is powerful enough, the IO code can be outlined and optimized > for size :) We have infrastructure for optimizing for size regions of functions, so this should be easy. With flag_reorder_blocks_and_partition we can even "outline" but problem with these things is that they do not really match the usual vision of profile prediction... Honza > > > >> based heuristics such as 'error, success, failure, fatal etc). > > > > yeah, this is also mentioned by some branch prediction papers. It is bit > > kludgy > > in nature (i.e. it won't understand programs written in Czech language) but > > it > > is an heuristics after all. > > > > right. > > thanks, > > David > > > Honza > >> > >> thanks, > >> > >> David > >> > >> > Honza > >> >> > >> >> thanks, > >> >> > >> >> David > >> >> > Honza
