[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
http://llvm.org/bugs/show_bug.cgi?id=1373
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
case.
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
alias:
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