[LLVMdev] Maintaining pass code outside of the LLVM directory

[John Criswell]

Trevor Harmon wrote:
> On Mar 22, 2010, at 9:53 PM, John Criswell wrote:
>
>   
>> You can always use the LLVM project infrastructure (documented at
>> http://llvm.org/docs/Projects.html).
>>     
>
> Thanks for reminding me of that. I had actually started out with a  
> project infrastructure, then switched to a pass implementation alone,  
> not realizing I could combine the two. I've now reverted back to my  
> old project, integrated the pass code into it, and my problem appears  
> to be solved.
>
>   
>> If you have any questions or have any problems, please email llvmdev.
>>     
>
> Well, there is one thing... I'm wondering how best to actually run the  
> pass after it's been compiled. Currently I'm just invoking "opt" and  
> passing it a "-load" parameter with the name of my pass's dynamic  
> library. I also have to add a couple more "-load" parameters for  
> external libraries needed by the pass, followed by the custom  
> parameters for the pass itself, and of course the "opt" parameters  
> (the name of a bitcode input file, etc.). It gets to be a rather long  
> and complex command line, and not a very friendly way of using the pass.
>
> Is there a better way? I suppose I could put the parameters in a shell  
> script -- simply a custom wrapper for "opt" -- and put it in the  
> project's tools directory. Or maybe I could write some kind of native  
> tool that bypasses "opt" altogether and somehow invokes the pass  
> through LLVM's API. But that might be overkill. Not sure how others  
> typically handle this. Any thoughts? Thanks,
>   

Either of the above solutions will work nicely.  There is also a third 
option if you're working on large applications: create a custom version 
of libLTO that runs your pass(es).  There are some people trying out 
this approach; it looks like a promising way to integrate passes 
seamlessly into the compiler toolchain.

FWIW, SAFECode uses both a special command line tool (based on opt's 
source code) and a specialized version of libLTO (which is young and 
needs further testing).  SAFECode's functionality is split into several 
libraries with circular dependences that I haven't cleaned out yet; 
using opt was quite unwieldy.

One caveat about designing your own command-line tool is that it is 
possible through subtle design decisions to create a situation where it 
is difficult or impossible to run your passes through bugpoint in the 
same fashion as they run inside your tool.  I don't think your project 
will have this problem because you only have a single pass, and your 
library dependences are probably linear.  However, if you have multiple 
passes in different libraries, and you have single command line options 
that affect the behavior of multiple passes, then it can become an issue.

The best way, I think, to deal with them should you ever have these 
issues are:

1) Don't write libraries with circular dependences.  Keep the 
dependences linear if possible.
2) Don't configure default pass behavior using constructor parameters.  
Instead, use a command-line option in the pass.  If a command-line 
option affects multiple passes, make an immutable pass with the command 
line option and have your passes query the command line option values 
from the immutable pass.

I apologize if I'm giving more answers than you need right now, but I've 
learned some of this stuff the hard way and hope to prevent others from 
following in my footsteps.
:)

-- John T.

> Trevor
>
>