[PATCH] Add llvm.experimental.patchpoint.double

[Philip Reames]

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>