[LLVMdev] Attribute to mark that function only access memory through it's arguments
Philip Reames
listmail at philipreames.com
Fri Jun 26 13:42:49 PDT 2015
I haven't heard any objection to the proposed attribute. Given that, I
think we can go ahead and move forward.
Igor - Can you update the patch to use the name argmemonly (analogous to
readonly, readnone)? As discussed, we want to factor out the read/write
part and use the existing attributes. Make sure you update the docs to
clarify the answer to Nick's question regarding following pointers.
Once that's done, I'll take a close look and probably LGTM. We will
need to find someone to review the bitcode/IR serialization though since
I'm not familiar with those pieces.
After this goes in, a good cleanup would be to remove the special casing
for intrinsics and have the td files drive the addition of the now
standardized attributes. This would be both a good cleanup and ensure
test coverage of the newly introduced attribute. As such, I'd like you
(Igor) to commit to doing this after the first patch lands.
Philip
On 06/19/2015 10:57 AM, Philip Reames wrote:
>
>
> On 06/18/2015 09:15 PM, Nick Lewycky wrote:
>>
>> Currently in AliasAnalysis we can model ModRef behaviour for
>> functions which
>> only access memory through their pointer arguments. However we can't
>> express this propery as a function attribute.
>>
>> For example, for intrinsics we can specify ReadWriteArgMem or
>> ReadArgMem
>> attributes in tablegen definitions. But due to the lack of the
>> related function
>> attributes on the llvm ir level, this intrinsics would be
>> modelled as if they
>> were clobbering arbitrary memory.
>>
>> It feels very naturall to add new function attribute which can
>> cover such cases.
>>
>> I have a patch (http://reviews.llvm.org/D10398
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10398&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=6QD3kOt2shxvhEw0pkmPGL_NzzjWw6s3ZTzBo-rwkUs&s=MJrrF5wf5KOXiTUsfpoJMSDYvyM_nZ3L79ZSsA9iXaA&e=>)
>> in which I added this
>> attribute. Currently there is some discussion on how to name it
>> and how it should
>> behave when defined together with other fucntion attributes.
>>
>>
>> What does it mean? Can it only touch memory that is directly referred
>> to by an argument? Or if that argument points to another pointer, can
>> we follow it?
> I just want to point out that the notion Igor is introducing as an
> attribute is not a new one. It's a prexisting notion which is already
> implemented within LLVM today; it's simply been restricted to
> intrinsics. Here's the definition from Intrinsics.td:
> // IntrReadWriteArgMem - This intrinsic reads and writes only from
> memory that
> // one of its arguments points to, but may access an unspecified
> amount. The
> // reads and writes may be volatile, but except for this it has no
> other side
> // effects.
> def IntrReadWriteArgMem : IntrinsicProperty;
>
> I did point out in the review that I think the notion of ReadsArgMem
> is redundant given the existing notions of ReadWriteArgMem and
> ReadOnly, but that's somewhat orthogonal. It's true of the existing
> implementation, not just Igor's patch. It may be worth settling on
> this to clarify naming (i.e. are we ever going to need an attribute
> like reads_arg_mem? Or can we be more generic and use
> accesses_arg_mem + readonly for the same purpose?), but I don't think
> that really changes the semantics in major ways.
>
> Philip
>
>
>
> _______________________________________________
> 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/20150626/cb06fb5e/attachment.html>
More information about the llvm-dev
mailing list