Re: Compiler-generated file access hints

Stefan Monnier <>
3 Apr 1997 14:12:00 -0500

          From comp.compilers

Related articles
Compiler-generated file access hints (Nor Jaidi) (1997-04-02)
Re: Compiler-generated file access hints (Stefan Monnier) (1997-04-03)
Re: Compiler-generated file access hints (Nor Jaidi) (1997-04-06)
| List of all articles for this month |

From: Stefan Monnier <>
Newsgroups: comp.compilers
Date: 3 Apr 1997 14:12:00 -0500
Organization: Compilers Central
References: 97-04-015
Keywords: optimize

Nor Jaidi <> 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

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.


Post a followup to this message

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