[LLVMdev] Attribute to mark that function only access memory through it's arguments

Igor Laevsky igor at azulsystems.com
Fri Jun 19 05:31:15 PDT 2015


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>


More information about the llvm-dev mailing list