llvm dev - Jun 2015 - [LLVMdev] Attribute to mark that function only access memory through it's arguments

Hi,

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

I wanted to get some feedback on this. Is this attribute required at all? Maybe
there is already a way of expressing such things?

Thanks,
Igor

On 18 June 2015 at 10:58, Igor Laevsky <igor at azulsystems.com> wrote:
> Hi,
>
> 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) 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 wanted to get some feedback on this. Is this attribute required at
all?
> Maybe
> there is already a way of expressing such things?
>
The other way today is a custom AA pass. That can either use deduction, or
special knowledge about named functions in your runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/5cd29184/attachment.html>

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?

Yes, idea is that we can’t follow pointer arguments to another pointers. In
other words, all memory operations in the function can refer to memory only
using pointers based on this function arguments.

— Igor

On 19 Jun 2015, at 07:15, Nick Lewycky <nlewycky at
google.com<mailto:nlewycky at google.com>> wrote:

On 18 June 2015 at 10:58, Igor Laevsky <igor at
azulsystems.com<mailto:igor at azulsystems.com>> wrote:
Hi,

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) 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 wanted to get some feedback on this. Is this attribute required at all? Maybe
there is already a way of expressing such things?

The other way today is a custom AA pass. That can either use deduction, or
special knowledge about named functions in your runtime.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/774ac3a4/attachment.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150619/6501c4b8/attachment.html>