[PATCH] D90479: [ValueTracking] ComputeKnownBits - minimum leading/trailing zero bits in LSHR/SHL (PR44526)

[Sanjay Patel via Phabricator via llvm-commits]

spatel added inline comments.


================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:1011-1012
     // the best folding opportunity.
     if (Known.hasConflict())
       Known.setAllZero();
     return;
----------------
RKSimon wrote:
> spatel wrote:
> > I'm not sure if it changes anything directly here, but we should revisit this conflict logic (similarly at the final block in the function) because we have a poison value in IR with D71126 (see also D92270).
> TBH - I don't think we should be setting 'known bits' to arbitrary/poison numbers like this inside ValueTracking - poison handling should be inside the shift combines and we should just return 'unknown' here. 
> 
> Is this something that needs to be addressed before this patch do you think? I've just kept to the current behaviour here so far.
I'm not sure if this patch exposes a new way for that clamp to zero to cause trouble, but I agree that we can return unknown state here and try to deal with the poison cases more directly in instsimplify or other passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90479