[cfe-dev] RFC: Clang driver redesign

[Hal Finkel]

On Fri, 2011-11-04 at 13:48 -0700, Eric Christopher wrote:
> 
> On Nov 4, 2011, at 1:08 PM, Matthieu Monrocq wrote:
> 
> > This would also allow implementing a *sane* option syntax, like for
> > example a hierarchical option parser:
> > 
> > --codegen-stackframe-limit=50
> > 
> > 
> > Where "stackframe-limit=50" is dispatched to the "codegen" plugin,
> > which itself dispatch "limit=50kB" to its stackframe object, which
> > sets its "limit" attribute to 50000 (for example).
> 
> There's one particular set of use cases that this brings up that I'd
> like to mention: 
> 
> 
> "Less knobs for users to use"
> 
> 
> I realize it's an example, and a good way of describing a partial way
> of evaluation options, however, the idea behind this option in
> particular is something I explicitly don't want to do. I believe we
> want less knobs, not more. We don't want the users mucking with things
> like inlining heuristics, the size of the stack, and whether they want
> to unroll 4 loops or 3. These are the kinds of decisions that the
> optimizer should be able to handle and people working on the compiler
> have their own ways of mucking with these sorts of options.

>From a scientific-programming perspective, I think that this is the
wrong way to approach the problem. Although I certainly understand the
desire to decrease the maintenance burden by restricting the number of
public-facing options, tuning things like loop-unrolling limits are
often necessary for squeezing the last bit of performance out of some
scientific code. There is a tendency to think, "but people should not
spend their time doing that"; and for the most part that is true. But
many places now have autotunners that attempt to find optimal compiler
parameters for specific routines on specific input data, and those
autotunners often work with multiple compilers and so the options that
they're tuning must be available using the command-line interface.

I think, however, that it is important to make a distinction between the
options that are designed to be public facing and those that are not.
For example, a public option could look like: -floop-unrolling-limit=200
while a non-public, could-change-at-any-time option could look like:
-finternal:loop-unrolling-limit=200. Options that have meanings that are
(mostly) independent of the underlying implementation, such has now many
instructions can be in an unrolled loop, stack sizes, etc. should be
made public. Other options should not, but should still be made
available. In this way, clang/LLVM will be as friendly as possible to
regular users, performance engineers, and compiler developers.

 -Hal

> 
> 
> -eric
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory