[PATCH] D65402: [Attributor][MustExec] Deduce dereferenceable and nonnull attribute using MustBeExecutedContextExplorer

[Hideto Ueno via Phabricator via llvm-commits]

uenoku added a comment.

In D65402#1696345 <https://reviews.llvm.org/D65402#1696345>, @jdoerfert wrote:

> In D65402#1696036 <https://reviews.llvm.org/D65402#1696036>, @uenoku wrote:
>
> > In D65402#1695253 <https://reviews.llvm.org/D65402#1695253>, @jdoerfert wrote:
> >
> > > In D65402#1694872 <https://reviews.llvm.org/D65402#1694872>, @uenoku wrote:
> > >
> > > > Currently, any use is not tracked so nothing about A[1] or A[-2] is deduced.
> > >
> > >
> > > As long as we have a test that is fine.
> > >
> > > > This would be solved once making it track gep instruction. But beforehand, I strongly suggest separating deduction for known/assumption respectively.
> > >
> > > What do you mean by the separation part?
> >
> >
> > I mean, running two different deduction scheme(known, assumption) might cause an unpredictable result.
> >
> >   define i32* @test_for_minus_index(i32* %p) {
> >     %q = getelementptr inbounds i32, i32* %p, i32 -2
> >     store i32 1, i32* %q
> >     ret i32* %q
> >   }
> >
> >
> > AANonNullArgument is composed of AAArgumentFromCallSiteArguments, AAFromMustBeExecutedContext.
> >  Assume that gep is tracked in `followUse`.
> >
> > Iteration 1 :
> >
> > - AAFromMustBeExecutedContext will traverse uses of `%p` and prepare uses of `%q` for next iteration.
> > - AAArgumentFromCallSiteArguments will call `indicatePessimisticFixpoint` because the function is not `internal` function. AANonNullArgument has already reached to pessimistic fixpoint so nonnull won't be deduced.
> >
> >   This example is so simple that we can debug them but it is hard to debug more complex ones.
>
>
> I see. You can explore uses exhaustively though that is a "local" solution to a general problem.
>  I think we need to keep known & assumed together but we should provide a way for AAs that have multiple deduction strategies to exhaust them seperatly, e.g, `AAArgumentFromCallSiteArguments` is known to have 2 schemes so we should track their "fixpoints" separate somehow.
>  In addition, or as an alternative, we could allow updates for AAs in a fixpoint if they opt-in to it. They would do so if they can improve based on known-information around them.


Looks good. Anyway, the current code maintains soundness ( "general" solution might not be reached) so I'll commit it if there is no problem.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65402/new/

https://reviews.llvm.org/D65402