On Mon, Jun 4, 2012 at 6:24 AM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka <hubi...@ucw.cz> 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?
Compiler can choose to do fine grained tuning based on heuristics which can be hard for user to do/maintain using annotation. For instance, we provide user __builtin_expect to annotate branches, but not a more general builtin to annotate the branch with specific probabilities -- the latter is taken care of by the compiler. thanks, David >> >> > >> > 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
