[PATCH] Add llvm.experimental.patchpoint.double
Philip Reames
listmail at philipreames.com
Thu Oct 9 14:25:47 PDT 2014
I like the general direction here. This is essentially introducing the
any type I mentioned in the other thread, but only for intrinsics.
Although, it seems like you might still have a problem.
For an example intrinsic "void foo(any)", we'd need unique "foo"
declarations for each of:
call void foo(i32 1)
call void foo(i8* nullptr)
call void foo(float 1.0)
Unless you want to extend the typing rules to allow "any" as a first
class IR type? That seems questionable.
I think you're going to end up exactly with the name mangling problem my
other patch tries to address. You're creating an explicit any type; I
was essentially creating the same thing via varadic intrinsics. I think
our patches are actually solving two different, but complementary problems.
If I'm missing something in your patch, please let me know.
Philip
On 10/09/2014 02:13 PM, Juergen Ributzka wrote:
> Hi Philip,
>
> the patch is incomplete, that is why I haven’t posted it yet. I
> attached it to show the general idea.
>
>
>
>
> Cheers,
> Juergen
>
>> On Oct 9, 2014, at 1:51 PM, Philip Reames <listmail at philipreames.com
>> <mailto:listmail at philipreames.com>> wrote:
>>
>> Has that been sent for review? I'd like to see that approach.
>>
>> p.s. Return is actually the easy case. You only need three versions
>> since you can use anyptr, anyint, and anyfloat. The complication
>> comes with function types, which are (at least for now) only needed
>> for the target.
>>
>> On 10/09/2014 01:46 PM, Andrew Trick wrote:
>>> Juergen has a tablegen patch that allows multiple return types on
>>> the same intrinsic, which should do exactly what you want without
>>> any extra name mangling.
>>>
>>> -Andy
>>>
>>>> On Oct 9, 2014, at 1:39 PM, Kevin Modzelewski <kmod at dropbox.com
>>>> <mailto:kmod at dropbox.com>> wrote:
>>>>
>>>> Oh interesting, that seems to work -- assuming that other people
>>>> like the approach, would you mind factoring out that part of your
>>>> statepoint patch?
>>>>
>>>> On Thu, Oct 9, 2014 at 9:19 AM, Philip Reames
>>>> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>>>>
>>>> On 10/08/2014 09:40 PM, Kevin Modzelewski wrote:
>>>>> Hi atrick,
>>>>>
>>>>> It didn't seem like there was anything special that had to be done besides
>>>>> just defining the new intrinsic with the different return type.
>>>>>
>>>>> It seems inelegant to create a new intrinsic for a new return type, but
>>>>> we're running into a case where we'd like to return a double through a patchpoint
>>>>> and I'm not sure of a better way to do that.
>>>> You might want to take a look at how we defined the gc_result
>>>> intrinsics in the statepoint patch which is currently up for
>>>> review. With some changes to the intrinsic name mangling, you
>>>> can define an intrinsic per "family" of types. The four we had
>>>> to add were: void, int, pointer, float. (float here means any
>>>> floating point type, int means any integer type, etc..)
>>>>> http://reviews.llvm.org/D5696
>>>>>
>>>>> Files:
>>>>> docs/StackMaps.rst
>>>>> include/llvm/IR/Intrinsics.td
>>>>> lib/CodeGen/SelectionDAG/FastISel.cpp
>>>>> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
>>>>> lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
>>>>> lib/IR/Verifier.cpp
>>>>> lib/Target/AArch64/AArch64TargetTransformInfo.cpp
>>>>> lib/Target/X86/X86TargetTransformInfo.cpp
>>>>> test/CodeGen/X86/patchpoint.ll
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141009/31290316/attachment.html>
More information about the llvm-commits
mailing list