llvm dev - Jul 2015 - [LLVMdev] String attributes for function arguments and return values

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
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
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

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

This sounds more like a use case for metadata. Can we attach metadata to
function arguments, or does that not work currently?

On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko <apilipenko at
azulsystems.com
> wrote:
>  Hi,
>
>  On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov> wrote:
>
> ----- Original Message -----
>
> From: "Artur Pilipenko" <apilipenko at azulsystems.com>
> To: llvmdev at cs.uiuc.edu
> Cc: "Hal Finkel" <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
> 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         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/36d973b7/attachment.html>

> 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>