[PATCH] D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value.

Hideto Ueno via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 23 01:47:08 PST 2019


uenoku added a comment.

In D71799#1794762 <https://reviews.llvm.org/D71799#1794762>, @baziotis wrote:

> In D71799#1794602 <https://reviews.llvm.org/D71799#1794602>, @uenoku wrote:
>
> > In D71799#1794464 <https://reviews.llvm.org/D71799#1794464>, @baziotis wrote:
> >
> > > Alright, that makes sense!
> > >  So, one quick question that I hope will help solve some issues: If `!SimplifiedV.hasValue()` but `ValueSimplifyAA.isKnown()`, then it is //known// that the value is `undef`?
> >
> >
> > It can't happen but it is semantically correct.
>
>
> It happens though :) Unless I messed up something. It happens with e.g. this code:
>
>   define i1 @ret_undef() {
>     ret i1 undef
>   }
>  
>   define void @cond_br() {
>     %cond = call i1 @ret_undef()
>     br i1 %cond, label %t, label %e
>   t:
>     ret void
>   e:
>     ret void
>   }
>
>
> And in the Attributor:
>
>   if (!SimplifiedV.hasValue()) {
>     if (ValueSimplifyAA.isKnown())
>       dbgs() << "IS IT UNDEF?\n";
>     ...
>   }
>
>
> I see the message. Sorry btw that I don't know exactly how `AAValueSimplify` works. When I started this patch, I assumed it was in everyone's best interest
>  to not spend time in it right now, so I'm guessing from looking small pieces of its code.


Sorry for my lack of words. I thought you were talking about in `updateImpl`. It can't happen **in updates** but can happen once reaches to a fix point.


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

https://reviews.llvm.org/D71799





More information about the llvm-commits mailing list