[llvm-commits] [PATCH] Expose scalar transforms to the c and ocaml bindings.

Gordon Henriksen gordonhenriksen at mac.com
Fri Mar 14 18:34:01 PDT 2008


Begin forwarded message:

> From: Erick Tryzelaar <idadesub at users.sourceforge.net>
> Date: March 11, 2008 02:26:39 EDT
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] Expose Pass and PassManager classes  
> to c and ocaml bindings.
> Reply-To: CVS Commit Messages for LLVM repository <llvm-commits at cs.uiuc.edu 
> >


Begin forwarded message:

> From: Erick Tryzelaar <idadesub at users.sourceforge.net>
> Date: March 11, 2008 02:42:21 EDT
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] Expose scalar transforms to the c  
> and ocaml bindings.
> Reply-To: CVS Commit Messages for LLVM repository <llvm-commits at cs.uiuc.edu 
> >

Begin forwarded message:
> From: Erick Tryzelaar <idadesub at users.sourceforge.net>
> Date: March 11, 2008 04:07:13 EDT
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] Expose Pass and PassManager classes  
> to c and ocaml bindings.
> Reply-To: CVS Commit Messages for LLVM repository <llvm-commits at cs.uiuc.edu 
> >


Hi Erick,

I'm going to take these patches as a basis, but go in a slightly  
different direction binding the classes. I observe:

The only thing that can be done with an LLVMFunctionPassRef is to  
convert it to an LLVMPassRef. I'd say it's not worthwhile to expose  
this type in the bindings.
Likewise, since Pass::~Pass isn't bound, the only thing that can be  
done with an LLVMPassRef is to add it to a pipeline or leak it.

Given these observations, I'm going to hide the memory management by  
fusing the create+add operations. There will be no need for the  
LLVMPassRef or LLVMFunctionPassRef types as a result.

To do this, and I'm going to also unify the PassManager and  
FunctionPassManager types, because otherwise each LLVMCreateSomePass  
routine would need to be overloaded for each type of pipeline; that  
would be cumbersome. This would be most straightforward by adding a  
common base class to the two, but Chris is virtual-hostile, so I'll  
probably new up a discriminated union instead. So there will only be  
one additional LLVM___Ref type.

I hope to provide an interface that can be used like this:

open Llvm
open LLvm_scalar_opts
open Llvm_target

let (++) f x = f x; x

let build_pipeline m =
   FunctionPassManager.create ()
     ++ add_target_data m
     ++ add_instruction_combining
     ++ add_reassociate
     ++ add_gvn
     ++ add_cfg_simplification


#include "llvm-c/Core.h"
#include "llvm-c/ScalarOpts.h"
#include "llvm-c/Target.h"

static LLVMPassManagerRef BuildPipeline(LLVMModuleRef M) {
   LLVMPassManagerRef PM = LLVMCreateFunctionPassManager();
   LLVMAddTargetData(PM, M);
   LLVMAddInstructionCombining(PM);
   LLVMAddReassociation(PM);
   LLVMAddGVN(PM);
   LLVMAddCFGSimplification(PM);
   return PM;
}

Thanks for all your contributions!

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080314/a0c74e12/attachment.html>


More information about the llvm-commits mailing list