[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