From: Pietro Braione <pietro.braione@un...> - 2013-10-15 11:39:16
Hello to all. I would like to express two personal wishes for 2.0, motivated by my personal experience with CIL and the recent support to plugins. I think that plugins should lead to a situation where:
1- complex CIL transformation passes are "unentangled" as compositions of basic ("primitive") ones;
2- that compositions of primitive transformations are expressed as plugin dependences, i.e., declaratively, leaving the task of "orchestrating" the composition to CIL, possibly in a dynamic fashion.
My wish comes out of a practical need. In my project I must eliminate just one of the many code transformations done by the simplify pass. Since you cannot separate (not even identify) the unwanted transformation inside simplify, you need to write a new pass. But this is not enough, because we want to replace simplify with ourOwnSimplify everywhere, but the passes that depend on simplify.ml invoke it directly simplify.ml. So there are only two alternatives: modify all the passes depending on simplify and patch their dependence (very ugly), or patch simplify.ml (still ugly but less). In both cases you need to rebuild CIL, which goes against the very idea of plugins, where you should just compile your extension and plug it in the architecture as dynamically as possible.
How far is CIL from this ideal? Would be happy to hear that we are already there.
From: Gabriel Kerneis <gabriel@ke...> - 2013-10-15 11:58:24
On Tue, Oct 15, 2013 at 01:23:46PM +0200, Pietro Braione wrote:
> How far is CIL from this ideal? Would be happy to hear that we are
> already there.
Not that far away. Let's imagine for a second that Simplify is split in
a series of simpler passes with well defined interfaces (.mli).
You can then reimplement one of them, as long as you respect the
interface. All you finally need to do is loading your implementation
instead the original one, either through a carefully designed list of
--load options, or by writing your own META file with the appropriate
dependencies. It should compose just fine with existing code, without
any need for recompiling existing plugins, as long as the mli matches.
You could even decide dynamically which plugin to load, with
Feature.loadWithDeps (currently undocumented but I could clean that up
if deemed necessary).
What you cannot replace are the modules embedded in the CIL library (see
src/cil.mllib for the complete list).
If you want to propose a patch splitting simplify.ml into several
sub-features, I would be glad to review it (note that currently, it
looks as if no other CIL plugin uses Simplify anyway). Please do not
hesitate to ask for further help, or publish a concrete example you are