llvm dev - Nov 2014 - [LLVMdev] propagating Globals modref information using metadata

Hi,

I am wondering why not put some or all of the information gathered in the
globals mod/ref information as metadata on loads and stores.

According to the alias documentation:
http://llvm.org/docs/AliasAnalysis.html#the-globalsmodref-aa-pass

"This pass implements a simple context-sensitive mod/ref and alias analysis
for internal global variables that don’t “have their address taken”. If a
global does not have its address taken, the pass knows that no pointers
alias the global. ... "

The globals mod ref pass can add metadata on each use of these internal
global variables if their addresses were not taken. Alias analyzer could
skip these addresses from all alias sets.

Thanks,
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141107/ad120397/attachment.html>

----- Original Message -----
> From: "ramshankar r" <ramshankar543 at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Friday, November 7, 2014 7:58:00 AM
> Subject: [LLVMdev] propagating Globals modref information using metadata
> 
> Hi,
> 
> I am wondering why not put some or all of the information gathered in
> the globals mod/ref information as metadata on loads and stores.
> 
> According to the alias documentation:
> http://llvm.org/docs/AliasAnalysis.html#the-globalsmodref-aa-pass
> 
> "This pass implements a simple context-sensitive mod/ref and alias
> analysis for internal global variables that don’t “have their
> address taken”. If a global does not have its address taken, the
> pass knows that no pointers alias the global. ... "
> 
> The globals mod ref pass can add metadata on each use of these
> internal global variables if their addresses were not taken. Alias
> analyzer could skip these addresses from all alias sets.
I don't think that adding metadata is the right solution. My thought is that
we should likely add globalsmodref-aa into the default optimization pipeline
(instead of adding it only during LTO) so that it can be used directly. I've
not had time to really experiment with this, but if you'd like to do so, I
think that would be good.

 -Hal
> 
> Thanks,
> Ram
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory