<div dir="ltr"><div>Hi Mugilan,</div><div><br></div><div>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:</div><div><br></div><div>* argmemonly</div><div>* inaccessiblememonly</div><div>* inaccessibleorargmemonly</div><div>* globalmemonly<br></div><div><br></div><div>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.</div><div><br></div><div>If we instead take a step back, we can recognize that there are different "paths" of accessing memory:</div><div><br></div><div>* arg</div><div>* global</div><div>* inaccessible</div><div>* indirect (i.e., via a pointer loaded from memory)</div><div>* other (e.g., pointer returned by black box function)</div><div><br></div><div>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:</div><div><br></div><div>* argmemonly -> noglobalmem noinaccessiblemem noindirectmem noothermem</div><div>* inaccessiblememonly -> noargmem noglobalmem noindirectmem noothermem</div><div>* inaccessibleorargmemonly -> noglobalmem noindirectmem noothermem</div><div>* globalmemonly -> noargmem noindirectmem noothermem (remember, you seem to want to allow access to inaccessible memory here)<br></div><div><br></div><div>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<br></div><div><br></div><div>Thoughts?</div><div><br></div><div>Cheers,</div><div>Nicolai<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 11, 2021 at 9:16 PM Mugilan Ganesan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">

Hello everyone,<br><br>We propose the addition of a GlobalMemOnly attribute to LLVM.<br><br>Definition:<br><br>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.<br><br>Motivation:<br><br>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.<br><br>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.<br><div><br></div><div>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.</div> Patches Overview: 1. Definition of GlobalMemOnly in the AsmParser, IR, and LLVM Bitcode. It is also defined in the LangRef. <a href="https://reviews.llvm.org/D109644" target="_blank">https://reviews.llvm.org/D109644</a> 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. <a href="https://reviews.llvm.org/D109647" target="_blank">https://reviews.llvm.org/D109647</a> 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.<br><br><a href="https://reviews.llvm.org/D109648" target="_blank">https://reviews.llvm.org/D109648</a><br><br>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.<br><br>Thanks,<br>Mugilan</div>

_______________________________________________<br>

LLVM Developers mailing list<br>

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>

</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.</div>