Re: Compiler-generated file access hints

Nor Jaidi <tuahanj@cs.curtin.edu.au> writes:
> Some papers suggested that the compiler should give the hints. But I
> haven't read any compiler-related issues regarding this. The compiler
> writers may not like this idea because of the following problems:


I'm sure there are ways to get around the problems you
mention. Basically, what you object to is the idea to have
file-specific optimisations, and I totally agree that it sounds
kludgy.


A "general" alternative is for the compiler to arrange for any kind of
prediction (prefetching being just one example) to be possible.


For instance, the compiler could generate a "skeleton" of the code
where only some operations (deemed worth predicting) are kept, along
with the one they depend on. And the operations themselves would be
replaced by "predictive" variants. Basically, you'd say "predict all
the opens, reads and writes" and the compiler would get rid of
anything unneeded and replace those calls by calls to "open_predict",
"read_predict", ...


No special string or file knowledge wouldn't be necessary any more in
the compiler. Of course, then you'll also have to make sure this
skeleton program is run "a little in advance".


This could then be applied also to precisely predict branches at run
time just a little before the branch actually happens, reducing
pipeline bubbles.


Or also memoizing functions could have a "_predict" variant that could
be called a little in advance.


                Stefan
--

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