[LLVMbugs] [Bug 1373] NEW: Some method to represent alias information in LLVM would be useful

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Mon Apr 30 17:05:30 PDT 2007


           Summary: Some method to represent alias information in LLVM would
                    be useful
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: christopher.lamb at gmail.com

>From this llvm-dev thread (http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-March/008323.html), 
Chris Lattner writes:

I think the goal should be to capture the most important information.  The
c99 definition of restrict has some nasty and complex implementation 
issues.  It may not be reasonable or interesting to capture every corner 

A more interesting question is how to represent TBAA information in LLVM 

Here is a sketch of a concrete proposal to get us started:

1. Add a new argument attribute "noalias", which can be applied to pointer
    formals and pointer function results.
2. Add a new intrinsic "i8* @llvm.noalias(i8*)

The semantics of 'noalias' are that they "define a new object".  Any 
pointer derived from it ("it" being the result of a no-alias call result, 
a formal parameter, or the result of llvm.noalias) is considered to not 

A. any other objects (e.g. global vars, allocas, functions, etc)
B. any other "noalias" objects
C. any other formal argument parameters or call results.

For these purposes, "pointers derived" means getelementptr and bitcast.

Can C99 restrict be mapped onto these semantics?  Is "C" really safe?

With these semantics, it is clear that 'calloc' could be declared to have 
a result pointer that is noalias for example, but I'm not sure if it would 
be safe to map restrict onto it.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

More information about the llvm-bugs mailing list