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

Mugilan Ganesan via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 11 12:16:28 PDT 2021

 Hello everyone,

We propose the addition of a GlobalMemOnly attribute to LLVM.


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


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.


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.


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.


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.

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

More information about the llvm-dev mailing list