[PATCH] llvm.noalias - BasicAA should look through them too

[Daniel Berlin]

On Thu, Apr 30, 2015 at 10:13 AM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:
> ================
> Comment at: include/llvm/IR/Value.h:404
> @@ -405,1 +403,3 @@
> +  const Value *stripPointerCasts(bool LookThroughNoAlias = false) const {
> +    return const_cast<Value*>(this)->stripPointerCasts(LookThroughNoAlias);
>    }
> ----------------
> dberlin wrote:
>> 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?)
>>
> In some sense both, but I also wanted to keep the default not to strip them.
After thinking about this, and talking to nick, i think we shouldn't ;)

First, API wise, it's makes for a somewhat API.  I don't see why these
are more special than anything else.  For example, nick wants to add
an "alias" intrinsic that says things are may-alias.

If there is really some mask of things that things want to stop at
when they are stripping, we should build that API.  Noalias just seems
like one of the possible things :)

We also need to quantify and know about any place that suddenly has to
care about noalias, and the easiest way to do that is to find the ones
that are stripping it and shouldn't be.


Note also that noalias is in fact, really a pointer cast.  it's a
pointer cast from an aliasing pointer to a non-aliasing one :)

>
> 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.

I would say the exact opposite.  Now you've made every place that
wants to get at underlying objects, including future users, have to
change :)

It should be the opposite. We should care where we need to (basicaa,
etc), and not care anywhere else.

If literally every transformation has to care about this all of the
sudden, we have larger problems.

>
> 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".

I"m more concerned with "pretty much everyone in the world now has to
know to pass true" :)

I mean, look just at how may places *you* changed :)
For pass fixing, it also seems really easy to write a noalias verifier
that says "if noalias appeared here before this pass, it should appear
after", and then let bugpoint find the bugs for us.



>
> 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.
>
> http://reviews.llvm.org/D9383
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>