[LLVMdev] Small problem with intrinsics

[Gordon Henriksen]

On Apr 21, 2008, at 13:00, Bart Coppens wrote:

> Hi Nicolas,
>
>> I guess that's because the value of the last argument of  
>> llvm.memcpy hasto be known at compile time.
>
> Hmmm ok, that's understandable, but it's also a bit of a problem for  
> me. I am writing a pass that creates a 'shadow' copy of each  
> function, so that I can do some bookkeeping with it, and then call  
> the original function afterwards. This would include intrinsics like  
> memcpy.
>
> Now, would it be possible to programmatically determine which  
> arguments are required to be constants? Then I would be able to  
> partially evaluate my custom function, so that multiple versions  
> would be emitted, each with the right constants in their call to  
> memcpy.
>
> (Given that LLVM seems to be pretty statically typed, it's rather  
> confusing that this kind of restriction isn't at least annotated in  
> the user-visible type, or isn't noticed by llvm-as.)


Intrinsics are special; they're really extensions to the LLVM IR, and  
you can't make any general assumptions about them. As an extreme  
example, @llvm.gcroot generates no code whatsoever at the call site,  
but influences codegen; you can't do AOP transformations upon it as  
you propose without utterly breaking its semantics.

The only safe course is to exclude call or invoke instructions where  
getIntrinsicID() != 0 from your transformation. For intrinsics that  
you do recognize, you can special-case them. In this case, you can do  
the equivalent of:

template <int align>
mymemcpy(...) {
     @llvm.memcpy(..., align);
}

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080421/3dc250ec/attachment.html>