llvm dev - Sep 2021 - [RFC] Adding a globalmemonly attribute for functions that only access global memory

Hello everyone,

We propose the addition of a GlobalMemOnly attribute to LLVM.

Definition:

This attribute indicates that the only memory accessed inside a function,
that is visible to the callee, is global memory. If the function reads or
writes other memory that is visible to the callee, the behavior is
undefined.

Motivation:

Memory attributes already exist for specifying the memory locations
accessed by a function, such as ArgMemOnly and InacessibleMemOnly.
Similarly, there are attributes for describing memory behaviour, such as
ReadOnly and WriteOnly.

However, no attributes exist for differentiating the types of memory
objects that functions can access, such as global objects and objects
created by alloca. We would like to start by introducing an attribute to
deal with functions that only access global objects.

The addition of the GlobalMemOnly attribute can benefit LLVM as follows:

1. Improves Alias Analysis, since this information can be used to improve
the determination of aliasing between functions and memory locations that
point to global objects.

2. Provides Transforms with greater information: many math lib calls only
modify the global variable errno. Unnecessary loads of the call arguments
can therefore be removed, since the calls will have no side-effects on them.

Patches Overview:

1. Definition of GlobalMemOnly in the AsmParser, IR, and LLVM Bitcode. It
is also defined in the LangRef.

https://reviews.llvm.org/D109644

2. Support is added to Alias Analysis. If a function is GlobalMemOnly and a
memory location does not point to a global object, getModRefInfo can infer
that no aliasing between the function and the location can occur. This
patch also adds a regression test for BasicAA.

https://reviews.llvm.org/D109647

3. Certain math lib calls are assigned GlobalMemOnly, since they only
modify the global variable errno. These calls include common functions,
such as atan, exp, and log.

https://reviews.llvm.org/D109648

Please let us know of any thoughts you may have regarding this attribute’s
implementation and use cases. We believe that it can strengthen LLVM’s
alias analysis and optimization passes if added.

Thanks,
Mugilan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210912/7670af2f/attachment.html>

Hi Mugilan,

I think this is an interesting direction. I've recently put some thought
into the memory attributes you mention for unrelated reasons, and found
that the various XYZonly attributes don't compose well, while noXYZ
attributes compose better.The reason is simple. With what you're proposing,
we end up with:

* argmemonly
* inaccessiblememonly
* inaccessibleorargmemonly
* globalmemonly

There are 4 attributes talking about 3 types of memory. Clearly, there are
orthogonality issues. First of all, glancing at your patch, your new
attribute should really be called inaccessibleorglobalmemonly. What if
somebody wants argorglobalmemonly? Do they add yet another attribute? That
way lies madness.

If we instead take a step back, we can recognize that there are different
"paths" of accessing memory:

* arg
* global
* inaccessible
* indirect (i.e., via a pointer loaded from memory)
* other (e.g., pointer returned by black box function)

These could map very nicely onto noXYZ attributes. You end up 5 attributes:
noargmem, noglobalmem, noinaccessiblemem, noindirectmem, noothermem. Nicely
composable, in particular today's attribute are mapped as follows:

* argmemonly -> noglobalmem noinaccessiblemem noindirectmem noothermem
* inaccessiblememonly -> noargmem noglobalmem noindirectmem noothermem
* inaccessibleorargmemonly -> noglobalmem noindirectmem noothermem
* globalmemonly -> noargmem noindirectmem noothermem (remember, you seem to
want to allow access to inaccessible memory here)

More importantly, the 5 attributes can express any future desired
combination, e.g. a function that accesses memory through argument
pointers, and through pointers loaded from there (transitively) is:
noglobalmem noinaccessiblemem noothermem

Thoughts?

Cheers,
Nicolai

On Sat, Sep 11, 2021 at 9:16 PM Mugilan Ganesan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello everyone,
>
> We propose the addition of a GlobalMemOnly attribute to LLVM.
>
> Definition:
>
> This attribute indicates that the only memory accessed inside a function,
> that is visible to the callee, is global memory. If the function reads or
> writes other memory that is visible to the callee, the behavior is
> undefined.
>
> Motivation:
>
> Memory attributes already exist for specifying the memory locations
> accessed by a function, such as ArgMemOnly and InacessibleMemOnly.
> Similarly, there are attributes for describing memory behaviour, such as
> ReadOnly and WriteOnly.
>
> However, no attributes exist for differentiating the types of memory
> objects that functions can access, such as global objects and objects
> created by alloca. We would like to start by introducing an attribute to
> deal with functions that only access global objects.
>
> The addition of the GlobalMemOnly attribute can benefit LLVM as follows:
>
> 1. Improves Alias Analysis, since this information can be used to improve
> the determination of aliasing between functions and memory locations that
> point to global objects.
>
> 2. Provides Transforms with greater information: many math lib calls only
> modify the global variable errno. Unnecessary loads of the call arguments
> can therefore be removed, since the calls will have no side-effects on
them.
>
> Patches Overview:
>
> 1. Definition of GlobalMemOnly in the AsmParser, IR, and LLVM Bitcode. It
> is also defined in the LangRef.
>
> https://reviews.llvm.org/D109644
>
> 2. Support is added to Alias Analysis. If a function is GlobalMemOnly and
> a memory location does not point to a global object, getModRefInfo can
> infer that no aliasing between the function and the location can occur.
> This patch also adds a regression test for BasicAA.
>
> https://reviews.llvm.org/D109647
>
> 3. Certain math lib calls are assigned GlobalMemOnly, since they only
> modify the global variable errno. These calls include common functions,
> such as atan, exp, and log.
>
> https://reviews.llvm.org/D109648
>
> Please let us know of any thoughts you may have regarding this attribute’s
> implementation and use cases. We believe that it can strengthen LLVM’s
> alias analysis and optimization passes if added.
>
> Thanks,
> Mugilan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210913/8b7a4bf5/attachment.html>

+1 to the overall proposal.  The use case makes sense and is worth 
handling.  Given the immediate benefit appears to mostly errno focused, 
I might have gone with a more specific errnomemonly flag, but since this 
proposal is broadly applicable and appears to solve enough of the errno 
problem to be useful, this seems fine too.

Nicolai raises an important point re: inaccessible memory that needs 
clarified in your patches.  I think this is mostly a naming and/or 
documentation clarity point though.

I happen to agree with both Nicolai and Johannes that we need to invert 
our current memory attribute structure, but as with Johannes, I would 
not want to make that blocking for this proposal.

Philip

On 9/11/21 12:16 PM, Mugilan Ganesan via llvm-dev wrote:
> Hello everyone,
>
> We propose the addition of a GlobalMemOnly attribute to LLVM.
>
> Definition:
>
> This attribute indicates that the only memory accessed inside a 
> function, that is visible to the callee, is global memory. If the 
> function reads or writes other memory that is visible to the callee, 
> the behavior is undefined.
>
> Motivation:
>
> Memory attributes already exist for specifying the memory locations 
> accessed by a function, such as ArgMemOnly and InacessibleMemOnly. 
> Similarly, there are attributes for describing memory behaviour, such 
> as ReadOnly and WriteOnly.
>
> However, no attributes exist for differentiating the types of memory 
> objects that functions can access, such as global objects and objects 
> created by alloca. We would like to start by introducing an attribute 
> to deal with functions that only access global objects.
>
> The addition of the GlobalMemOnly attribute can benefit LLVM as follows:
>
> 1. Improves Alias Analysis, since this information can be used to 
> improve the determination of aliasing between functions and memory 
> locations that point to global objects.
>
> 2. Provides Transforms with greater information: many math lib calls 
> only modify the global variable errno. Unnecessary loads of the call 
> arguments can therefore be removed, since the calls will have no 
> side-effects on them.
>
> Patches Overview:
>
> 1. Definition of GlobalMemOnly in the AsmParser, IR, and LLVM Bitcode. 
> It is also defined in the LangRef.
>
> https://reviews.llvm.org/D109644 <https://reviews.llvm.org/D109644>
>
> 2. Support is added to Alias Analysis. If a function is GlobalMemOnly 
> and a memory location does not point to a global object, getModRefInfo 
> can infer that no aliasing between the function and the location can 
> occur. This patch also adds a regression test for BasicAA.
>
> https://reviews.llvm.org/D109647 <https://reviews.llvm.org/D109647>
>
> 3. Certain math lib calls are assigned GlobalMemOnly, since they only 
> modify the global variable errno. These calls include common 
> functions, such as atan, exp, and log.
>
> https://reviews.llvm.org/D109648 <https://reviews.llvm.org/D109648>
>
> Please let us know of any thoughts you may have regarding this 
> attribute’s implementation and use cases. We believe that it can 
> strengthen LLVM’s alias analysis and optimization passes if added.
>
> Thanks,
> Mugilan
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210914/b177ea63/attachment-0001.html>