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

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

On 07/14/2015 05:07 PM, Pete Cooper wrote:
>
>> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com 
>> <mailto: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.
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.

Philip
>>
>> 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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/2338c4b6/attachment.html>

On Tue, Jul 14, 2015 at 9:01 PM Philip Reames <listmail at
philipreames.com>
wrote:
> On 07/14/2015 05:07 PM, Pete Cooper wrote:
>
>
>  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.
>
> 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 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/365a12e9/attachment.html>

> On Jul 14, 2015, at 8:53 PM, Philip Reames <listmail at
philipreames.com> wrote:
> 
> On 07/14/2015 05:07 PM, Pete Cooper wrote:
>> 
>>> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com
<mailto: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.
> 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.
No objection from me.  Seems like an arbitrary restriction for it to currently
work on everything other than arguments.

If you or anyone else wants the metadata in attribute sets, we can have another
discussion for that.  My use cases were tbaa on arguments and range metadata,
but there could easily be others.

Cheers,
Pete
> 
> 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.
> 
> Philip
>>> 
>>> 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 <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 <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>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/7fa09a4e/attachment.html>