[Bug tree-optimization/92233] missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Rather than jump threading what I think we want is the ability to note that the two object's values are related. In this specific example, in the THEN arm we know that at least one of them must be zero and thus the result of the multiplication must be zero. This kind of relational tracking is also helpful to jump threading and false positive elimination for the various middle end warnings. There's one or more other BZs which show that, but I don't know their #s offhand.
[Bug tree-optimization/92233] missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-28 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- It's kind-of tail-duplication that is required here. The jump threading code can likely be abused here but the important thing is of course the costing where unlike with jump-threading, there's no branch that will go away. In theory (and with --param logical-op-non-short-circuit=0) GVN PRE could also see that the multiplication result is fully available on both arms (but the VN part doesn't know about conditional equivalences [yet]). That said, it's a value-numbering issue as soon as (like here) a value is always known to have some specific value. But yes, it might be easier to have another transform simplify the problem for us. Oh, and logical-op-non-short-circuit manifests itself too early.
[Bug tree-optimization/92233] missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233 --- Comment #1 from Marc Glisse --- (llvm doesn't do it either) Would some kind of threading be the most natural way to handle this? If the compiler duplicates the code as if (a==0) return a*b; else if (b==0) return a*b; then it becomes easy to optimize. There could be a heuristic to encourage the compiler to do that when the test is var == cst and var is used in an operation that greatly simplifies for cst. On powerpc64le-linux-gnu (so the 2 tests aren't combined as bit_ior), if I test test_mul(a,b)==0 in another function, it does simplify to true, with DOM2 doing the interesting part.
[Bug tree-optimization/92233] missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
