-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some method to represent alias information in LLVM would be useful #1745
Comments
This patch adds "NoAlias" to ParamAttr namespace's list of Attributes |
all 3 patches look good, plz apply. In the future, please submit proposed patches to llvm-commits. -Chris |
Information from Chris, this clearly explains why we need the intrinsic Consider if you have something like this: void foo(restrict *P1, restrict *P2) { In this case, obviously P1 and P2 don't alias. Now consider this: void bar(void *P1, void *P2) { Imagine if we inlined the function, we'd get this: void bar(void *P1, void *P2) { Now we have to assume the pointer alias, we lost information. I'm void bar(void *P1, void *P2) { which we can now decide don't alias. The problem with this approach is that the intrinsics would block These intrinsics could also be used to translate code like this: restrict int *G; void bar() { *G; } into -> void bar() { Thanks, Chris :) |
happy to help :) |
BasicAA has been taught about noalias function arguments. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070730/052392.html |
It appears BasicAliasAnalysis.cpp does have an AddressMightEscape routine, which could be used to improve the analysis of queries involving a noalias pointer and a pointer with an unknown base. If the noalias pointer doesn't escape, then there is no alias. They key is to make sure that the logic for finding a base object always succeeds for expressions on which AddressMightEscape returns false. |
Acomplia |
The content of attachment 1352 has been deleted by The token used to delete this attachment was generated at 2008-01-25 11:29:20. |
We now support the noalias attribute, and have another PR to track the work for TBAA, closing as fixed. |
mentioned in issue llvm/llvm-bugzilla-archive#1582 |
Extended Description
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:
formals and pointer function results.
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.
The text was updated successfully, but these errors were encountered: