[LLVMdev] String attributes for function arguments and return values

Tue Jul 14 22:15:15 PDT 2015

>
>
>  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.
>
> For the particular use case we have, metadata on arguments would be a
> better semantic fit.  It's a pure optimization hint.  Having said that,
> attributes work just fine in practice as well.
>

I guess as long as they're not upstreamed you can do whatever you'd like,
I'd suggest the metadata though just to keep within the llvm design
principles.

>  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 :)
>
> Let me restate my previous comment: Having support for custom attributes
> on function arguments is generally useful for external users of LLVM.
> Whether it is ideal in this particular case is not really relevant.  There
> are certainly reasonable cases where using a target/environment specific
> attribute to effect call lowering makes perfect sense.  It seems desireable
> to be able to prototype these quickly so that they can mature and
> (possibly) make it upstream.
>
>
There's a lot of things that are generally useful that we delete. I don't
see anything unused in any other way. Bitcode support is a bit more...
solid though so removing anything that exists is harder. Misfeatures or
things accidentally supported have a tendency to stick around and
complicate things.

That said...

> My view is that we *already* support these attributes.  I don't have an
> example user, but it really wouldn't surprise me if folks were using this
> functionality already.  Everything works if generated through the C++ APIs
> or read from bitcode.  It's only the deserialization parts that break.  In
> particular, you can have a working compiler which generates output which
> isn't parseable by LLVM's existing tools.  That's not exactly a good state
> to be in.
>
>
I don't have a strong opinion here as I said in the first place. If fixing
this support is useful then I've no objection.

-eric

>
>  -eric
>
>
>
>
>>  Philip
>>
>>
>> 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
>>> <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         http://llvm.cs.uiuc.edu
>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://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/20150715/8e6aec2b/attachment.html>