[PATCH] Mangling for intrinsic names w/function type parameters
atrick at apple.com
Tue Jul 22 11:33:53 PDT 2014
> On Jul 22, 2014, at 11:12 AM, Juergen Ributzka <juergen at apple.com> wrote:
> 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)
That would be ideal. I think what Philip is saying is that it wouldn’t pass LLVM verification without a bitcast. I was actually imagining you would have to do something like:
declare double @llvm.experimental.patchpoint.double(i64, i32, double(…)*, i32, …)
%t = bitcast double(i64)* @foo to double(…)*
call double (...)* @llvm.experimental.patchpoint.double(i64 0, i32 20, double(...)* %t, i32 1, i8 0)
But that doesn’t seem to be supported yet either.
Whatever solution we come up with, my requirement is that LLVM cannot have a-priori knowledge of all possible runtime function signatures, and the front end needs to be able to add runtime function types without extending LLVM.
I also think it be kind of horrible to have an intrinsic opcode for every signature.
> 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.
More information about the llvm-commits