[PATCH] D78503: [ValueTracking] Let analyses assume a value cannot be partially poison

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 22 16:20:54 PDT 2020


aqjune marked an inline comment as done.
aqjune added inline comments.


================
Comment at: llvm/lib/Transforms/Instrumentation/PoisonChecking.cpp:347
    - and/or - It would seem reasonable for poison to propagate from both
-     arguments, but LangRef doesn't state and propagatesFullPoison doesn't
-     include these two.
+     arguments, but LangRef doesn't state.
    - all binary ops w/vector operands - The likely interpretation would be that
----------------
jdoerfert wrote:
> aqjune wrote:
> > aqjune wrote:
> > > jdoerfert wrote:
> > > > Is this true? I mean, don't you check for binary operands above?
> > > It was my misunderstanding about the code, updated.
> > BTW, what do you think about making this explicit in LangRef? I can make a patch for this.
> > If and/or blocks poison propagation, removal of trivial and/ors becomes invalid, because it makes the resulting program more poisonous.
> > 
> > 
> That's a good question. I guess we could either say that bits you "overwrite" with and/or are not poison anymore but I am unsure that is what we want. The problem is that various operations could be used to fix bits and we should handle them all the same (x = y - y, x = y * 0, ...).
> 
> That said, we should have a discussion (= ask others).
I can run Alive2 with several semantics on or/and & see what kind of optimizations are allowed/disallowed. It may take some time, but can be done by Friday.
I'll leave the result + references to relevant people at D78615.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78503





More information about the llvm-commits mailing list