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

[Philip Reames]

Hi atrick, ributzka, nlewycky, chandlerc,

This diff is not intended to be submitted in it's current form, but is primarily to spark discussion.  

Currently, we have a type parameter mechanism for intrinsics.  Rather than having to specify a separate intrinsic for each combination of argument and return types, we can specify a single intrinsic with one or more type parameters.  These type parameters are passed explicitly to Intrinsic::getDeclaration or can be specified implicitly in the naming of the intrinsic function in an LL file.  

Today, the types are limited to integer, floating point, and pointer types.  With a goal of supporting symbolic targets for patchpoints and statepoints (out of tree GC support), I would like to extend this mechanism to handle other types.  In particular, I want to parametrize the intrinsics by function types.  

I'm looking for feedback on what mangling scheme do we want to use?  In particular, how do we make it play well with type and function renaming in the IR?  I'm utterly unfamiliar with this code, so I'm hoping for feedback from folks who may understand the current scheme, it's motivations, and usage.  

I've implemented a straw man proposal, but I suspect we'll want to find something better.  

Note: The interesting implementation is in Function.cpp.  The test case is useful for understanding the context and the mangling scheme.  I've included a change to the patchpoint intrinsic to highlight the intent, but that change is incomplete and currently breaks every other patchpoint test.

http://reviews.llvm.org/D4608

Files:
  include/llvm/IR/Intrinsics.td
  lib/IR/Function.cpp
  test/CodeGen/X86/stackmap-generic.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D4608.11721.patch
Type: text/x-patch
Size: 8930 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140721/dce60098/attachment.bin>