[PATCH] Mangling for intrinsic names w/function type parameters

[Juergen Ributzka]

I think Andy was referring to the test case were the name mangling creates a new intrinsic declaration for each function that is wrapped with a patchpoint. Is the mangling really required?

The reason why we originally created only two patchpoint versions was because tblgen doesn’t allow you to generate intrinsic with wildcard return types - unless they are tied to an input argument type.

To support symbolic function names as arguments wouldn’t it be just enough to extended tblgen to allow intrinsic with a wildcard return types and teach the patchpoint intrinsic to take a symbolic function as an argument and get all the information it needs from the function’s declaration?

something like:
declare double @foo(i64)
declare double @llvm.experimental.patchpoint.double(i64, i32, i8*, i32, …)
...
call double (...)* @llvm.experimental.patchpoint.double(i64 0, i32 20, double(i64)* @foo, i32 1, i8 0) 

Cheers,
Juergen


On Jul 22, 2014, at 9:33 AM, Philip Reames <listmail at philipreames.com> wrote:

> On 07/21/2014 06:07 PM, Andrew Trick wrote:
>> I might be missing something. But I think that LLVM should have a small finite number of intrinsics for patchpoint, and the frontend (JIT client) should be able to pass it a symbolic target with any signature. In other words, we should always treat the target arguments as varargs from the intrinsic's point of view. That doesn't change the actual calling convention used.
> Andy, I think you may have misread the change.  The suggestion is not changing either the calling convention or the encoding of the arguments passed to the target function.  It's changing the type of the target function itself.  Instead of being an i8*, it could be a void(int)* for example.  The intrinsic would become parametric with the type of the target.
> 
> Currently, you have to explicitly bitcast your function type to an i8* before passing it to the patchpoint.  This change would remove that requirement.
>> 
>> http://reviews.llvm.org/D4608
>> 
>> 
>