On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk@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.
         As far as I can tell, the string attributes on function parameters     is already "supposed to work".  We support it in bytecode.  We even     support serialization of the attributes.  It's just the parsing     that's broken.  I don't have any problem with an eventual move     towards supporting metadata on arguments, but does anyone object to     landing the current patches?  Whether we believe that the use case     motivating the patch is better represented by metadata or not,     having the deserialization support seems like a clear improvement.      
    
    As a side note, I can't find any mention of the string attribute     functionality in the LangRef or ExtendingLLVM.  Seems like it might     be time to add something about the capability for extension.  We     should probably also *explicitly* reserve the entire namespace of     possible keywords for future LLVM in tree enhancements.  
    

So as far as the attribute versus metadata question here I don't have a particular care whether or not we support attributes on any particular thing in the Value hierarchy. As far as your particular case I really only have one question: are the attributes needed for correctness or for optimization? If they're the latter they should probably be metadata, the former then attributes seem to make the best sense.

Mostly just trying to see about you getting the right fixes in for the support you need and the rest of us not having to worry about not breaking things that no one cares about :)

-eric


 
    Philip
           
                   
            
              On Mon, Jul 13, 2015 at 7:42 AM,                 Artur Pilipenko <apilipenko@azulsystems.com>                 wrote:
                                                        Hi,                     

                      
                                                       
On 13 Jul 2015, at 15:59, Hal                               Finkel <hfinkel@anl.gov>                               wrote:
                            
                            
----- Original Message -----                                                                From: "Artur Pilipenko" <apilipenko@azulsystems.com>
                                To: llvmdev@cs.uiuc.edu
                                Cc: "Hal Finkel" <hfinkel@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
                                                       
                        
                      
                      
                    
                  
                  
                  _______________________________________________
                  LLVM Developers mailing list
                  LLVMdev@cs.uiuc.edu                           http://llvm.cs.uiuc.edu
                  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
                  
                               
              
                         _______________________________________________
            LLVM Developers mailing list
            LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
            http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
                                 
      
      
      
      
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
         
  ">

(original) (raw)



On Tue, Jul 14, 2015 at 9:01 PM Philip Reames <listmail@philipreames.com> wrote:
On 07/14/2015 05:07 PM, Pete Cooper wrote:

On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk@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.
As far as I can tell, the string attributes on function parameters is already "supposed to work". We support it in bytecode. We even support serialization of the attributes. It's just the parsing that's broken. I don't have any problem with an eventual move towards supporting metadata on arguments, but does anyone object to landing the current patches? Whether we believe that the use case motivating the patch is better represented by metadata or not, having the deserialization support seems like a clear improvement.

As a side note, I can't find any mention of the string attribute functionality in the LangRef or ExtendingLLVM. Seems like it might be time to add something about the capability for extension. We should probably also \*explicitly\* reserve the entire namespace of possible keywords for future LLVM in tree enhancements.


So as far as the attribute versus metadata question here I don't have a particular care whether or not we support attributes on any particular thing in the Value hierarchy. As far as your particular case I really only have one question: are the attributes needed for correctness or for optimization? If they're the latter they should probably be metadata, the former then attributes seem to make the best sense.

Mostly just trying to see about you getting the right fixes in for the support you need and the rest of us not having to worry about not breaking things that no one cares about :)

-eric


Philip


On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko <apilipenko@azulsystems.com> wrote:
Hi,

On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel@anl.gov> wrote:

----- Original Message -----
From: "Artur Pilipenko" <apilipenko@azulsystems.com>
To: llvmdev@cs.uiuc.edu
Cc: "Hal Finkel" <hfinkel@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


\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
LLVM Developers mailing list  
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu  
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________

LLVM Developers mailing list

LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev