[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