[LLVMdev] String attributes for function arguments and return values

[Pete Cooper]

> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> This sounds more like a use case for metadata. Can we attach metadata to function arguments, or does that not work currently?
We can’t, no.

I have an out of tree patch which allows metadata in AttributeSets.  This would also potentially also work here.

However, depending on the number of unique strings/metadata in AttributeSets, this could get large.  I don’t think we’ve ever had more that a few unique AttributeSets in an entire module.  If you have too many different strings then you could have a significant number of sets which could get slow.

Metadata attached to the function or the function arguments is likely to scale better than strings/metadata in the AttributeSets, but I guess it all depends on whether many are even needed.

Pete
> 
> On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko <apilipenko at azulsystems.com <mailto:apilipenko at azulsystems.com>> wrote:
> Hi,
> 
>> On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
>> 
>> ----- Original Message -----
>>> From: "Artur Pilipenko" <apilipenko at azulsystems.com <mailto:apilipenko at azulsystems.com>>
>>> To: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>
>>> Cc: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>>
>>> Sent: Monday, July 13, 2015 6:45:35 AM
>>> Subject: String attributes for function arguments and return values
>>> 
>>> Hi,
>>> 
>>> I’d like to support string attributes on function arguments and
>>> return values. We are going to use them in our tree to express
>>> higher level language types.
>> 
>> How do you expect to use this information? Will you need the inliner to do something special with these?
> Type information is required for Java specific optimizations, like devirtualization, subtype check optimizations, etc. There are no plans to upstream them, because they are too specific to Java.
> 
> W.r.t inlining I don’t think that these attributes will require any special handling.
> 
> Artur
> 
>> 
>> Thanks again,
>> Hal
>> 
>>> 
>>> Internally attributes framework have everything to do this, it’s even
>>> possible to generate string attributes via API right now:
>>> Function *function;
>>> function->setAttributes(function->getAttributes().addAttribute(context,
>>> i, "attribute"));
>>> But because it’s not supported in LLParser if you dump the function
>>> and try to parse it back it will fail. I have a patch to fix this
>>> problem:
>>> http://reviews.llvm.org/D11058 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11058&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=QxcZ1dQY-4Fptsg8J_QZvUH5zX3_zJfFtYe_mFFV434&s=yDXYh5H5eycn3Yn6A7bDimwo8jVbqaGav2FdRRIz0lg&e=>
>>> I consider this part as a bug fix for existing functionality.
>>> 
>>> The second patch is to add accessors to string attributes to Argument
>>> and Function classes:
>>> http://reviews.llvm.org/D10872 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10872&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=x-SxyqtoLVC9ndWtSNBJBeyYQml3MZ2Ch4L_B4Hc3Yg&s=a-NOt0poEqPq0I1bAMlsGTKRbxjviviAhMjJ41PNN2Y&e=>
>>> This part is optional because there no code in upstream will make use
>>> of it. But if we support string attributes syntax it makes sense to
>>> provide API support as well.
>>> 
>>> Does anyone have any objections?
>>> 
>>> Thanks,
>>> Artur
>>> 
>>> 
>>> 
>> 
>> -- 
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/ef7ab950/attachment.html>