Motivated by the work on the llvm.noalias intrinsic, teach BasicAA to look through returned-argument functions when answering queries. This is essential so that we don't loose all other AA information when supplementing with llvm.noalias.
Details
Diff Detail
Event Timeline
Also, the ability to optionally strip llvm.noalias calls as pointer casts added here is also used in several later patches.
include/llvm/IR/Value.h | ||
---|---|---|
404 | So, is there actually a place you plan on not passing true here, or are you just trying to keep existing logic where you haven't explicitly modified it? (Because i am having a bit of trouble seeing where you would want to pass false. At the point you are stripping, why is noalias more magical to not strip than anything else that can appear here?) |
include/llvm/IR/Value.h | ||
---|---|---|
404 | In some sense both, but I also wanted to keep the default not to strip them. At least in theory, looking through casts and stripping llvm.noalias calls could lead to rewriting the pointer in terms of some underlying object (thus removing the aliasing information) -- SROA might do this for example -- and so I thought it would be easier to vet specific uses that we know won't do this. Generically, I thought that "I added restrict and my code slowed down" will be easier to correct than "I added restrict and my code did not speed up as it should have". We could certainly change the default (and thus remove the need for several of the patches in this series ;) ). I don't have a strong opinion. |
include/llvm/IR/Value.h | ||
---|---|---|
404 | After thinking about this a lot, i'm strongly of the opinion we should just change the default. I think anything else is likely to create a mess :) In fact, i'd go further, and say this shouldn't be a parameter at all. If someone wants a function that stops at noalias, they should write a new strip function. I don't think noalias is special enough, and can't think of a real use case, for wanting to stop there. |
Resigning as a reviewer to get a very stale review off my list of blocking tasks in phabricator. Please reopen when desired.
Rebased. As Danny requested, the Boolean parameters to stripPointerCasts have been removed; they now always look through the noalias intrinsics. This means that we need to prevent InstCombine and friends from removing the noalias intrinsics from the pointer-value use-def chains some other way. As a result, this particular patch is now much simpler.
Changed from being specific to llvm.noalias to applying to all returned-argument functions.
So, is there actually a place you plan on not passing true here, or are you just trying to keep existing logic where you haven't explicitly modified it?
(Because i am having a bit of trouble seeing where you would want to pass false. At the point you are stripping, why is noalias more magical to not strip than anything else that can appear here?)