Implementing customized intrinsic

Dear all,

Currently I'm working on a project that add various checks into the LLVM bitcode. For example, I insert function calls before every load / store instructions to guarantee that these instructions are safe. I really want to implement them as LLVM intrinsics or ``special function calls'' so that I am able to leverage the power of things like InstVisitor. However, it seems it is difficult to do it without changing LLVM's source codes, cause

i) all constructors of CallInst are private
ii) There's no interfaces for implementing customized intrinsics (without changing intrinsics*.td)

It is very helpful to mark these checks as special calls (like intrinsics), it would ease the implementation of optimizations since they only work on these special calls, say, I could save some information in the subclass of CallInst.

I also notice that the access identifier of CallInst are changed after LLVM 2.0. I would be appreciated if you guys could explain the rationale behind the changes.

Thank you very much.

Best,

Haohui

Dear all,

Currently I'm working on a project that add various checks into the
LLVM bitcode. For example, I insert function calls before every
load / store instructions to guarantee that these instructions are
safe. I really want to implement them as LLVM intrinsics or ``special
function calls'' so that I am able to leverage the power of things
like InstVisitor. However, it seems it is difficult to do it without
changing LLVM's source codes, cause

i) all constructors of CallInst are private
ii) There's no interfaces for implementing customized intrinsics
(without changing intrinsics*.td)

It is very helpful to mark these checks as special calls (like
intrinsics), it would ease the implementation of optimizations since
they only work on these special calls, say, I could save some
information in the subclass of CallInst.

I also notice that the access identifier of CallInst are changed after
LLVM 2.0. I would be appreciated if you guys could explain the
rationale behind the changes.

Thank you very much.

Best,

Haohui

Does the llvm annotation intrinsic not work for what you are trying to do?

http://llvm.org/docs/LangRef.html#int_var_annotation
http://llvm.org/docs/LangRef.html#int_annotation

-Tanya

Thanks for your reply. Probably I did not explain clearly. Here is an example:

call @check(%foo)
%1 = load %foo

Now I want to write optimization only focus on the function call @check, and it might have some additional information which does not need to appear at LLVM IR.

So it seems that the annotation intrinsic does not fit the scenario.

Haohui

call @check(%foo)
%1 = load %foo

Now I want to write optimization only focus on the function call
@check, and it might have some additional information which does not
need to appear at LLVM IR.

So it seems that the annotation intrinsic does not fit the scenario.

I still don't understand.

Why not just replace the call to check with a call to the llvm var annotation intrinsic and then you can pass anything you want to it. Such as your "check" string. Then you write a pass that looks for these. Why would that not work? The var annotation is specifically designed to annotate local variables with arbitrary strings.

-Tanya

Haohui Mai wrote:

Thanks for your reply. Probably I did not explain clearly. Here is an
example:

call @check(%foo)
%1 = load %foo

Now I want to write optimization only focus on the function call
@check, and it might have some additional information which does not
need to appear at LLVM IR.
  

Are these the SAFECode run-time checks, or are these some other
instrumentation? What are the limitations you're running into with
these function calls? Are other optimization passes not able to
optimize the call instructions because they make conservative
assumptions about the functions being called in the call instruction?
Is there information that you'd like to associate with the calls that
currently cannot be done in the IR? Is there information that should be
passed between LLVM passes that you think shouldn't be represented in
the IR? Or is there some other limitation that you're encountering?

-- John T.