[LLVMdev] Alternative to Adding New Intrinsics for Code-Generation?

John McCall rjmccall at apple.com
Thu Mar 10 11:50:14 PST 2011


On Mar 10, 2011, at 11:11 AM, Dan Bailey wrote:

> John McCall wrote:
>> 
>> On Mar 10, 2011, at 10:43 AM, Dan Bailey wrote:
>>   
>>> I've written an IR->IR translation as part of a high-level language I've 
>>> designed. It replaces my own specific functions in LLVM passes with 
>>> custom logic.
>>> 
>>> As part of the process, it needs to perform constant propagation and 
>>> inlining prior to doing any translation. Initially I just used simple 
>>> function declarations to define these specific functions, but the 
>>> verification pass requires that each function declaration also has a 
>>> definition. Without wanting to create dummy function definitions, I 
>>> found I had to introduce new intrinsics, which does what I want but is 
>>> obviously not desired.
>>> 
>>> How can I do this without using intrinsics? I looked for function 
>>> attributes to see if I can flag a function as not requiring a 
>>> definition, but there doesn't seem to be any. It would be useful to 
>>> ignore a function as if it was an intrinsic during this prior stage of 
>>> passes. Any suggestions would be welcome?
>>>     
>> 
>> The verifier certainly doesn't object in general to function declarations.
>> I'm guessing that the problem is that you're giving your declarations
>> internal linkage, which is indeed an error for normal functions.  The
>> solution is to not give these "intrinsics" internal linkage when you
>> declare them.
>> 
>> John.
>>   
> 
> That makes sense, but it's not working for me. All the functions are defined as ExternalLinkage, this is (a simplified version of) the pre-optimised ir:
> 
> declare i32 @_function(i32, i32, i32)
> 
> define i32 @Test() {
> entry:
>   %value = call i32 @_function(i32 0, i32 0, i32 0)
> }
> 
> Which generates this error in the verifying stage:
> 
> Referencing function in another module!
>   %value = call i32 @_function(i32 0, i32 0, i32 0)

That's asserting that @Test and @_function are in different llvm::Modules.  That's a memory well-formedness constraints, not an IR constraint.  That should honestly be getting checked for intrinsic functions, too.

John.



More information about the llvm-dev mailing list