[PATCH] D69748: [Attributor][IPConstantProp] Run the Attributor on IPConstantProp tests

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 2 17:28:47 PDT 2019


jdoerfert added a comment.

In D69748#1731344 <https://reviews.llvm.org/D69748#1731344>, @fhahn wrote:

> As mentioned in D69747 <https://reviews.llvm.org/D69747> already, I am not too happy with the tests here to mix testing IPSCCP and IPConstantPropagation; I think it's valuable to just have a single target to run the relevant tests. Would it make sense to group the attributor tests together in a directory?


I do not disagree but it is not as simple. I want to reuse existing test without copying them while the Attributor is still under development and needs to coexists with what we have. (It probably will stay that way for some passes we want to "share tests with", see below.) If we could use softlinks that would be great, otherwise I will probably ignore this minor issue and continue to run: `llvm/test/Transforms/{IPConstantProp,FunctionAttrs,InferFunctionAttrs,ArgumentPromotion}`

> Also, unfortunately I did not have time to followd the attributor development closely lately, I am just curious: is there a benefit of doing some value simplifications in attributor directly?

TL;DR, I think so yes, at least in the short term. How we want to go forward once the Attributor matured fully is an open question.

There are reasons, but, as always, it is not a clear win. So perfect world, we have a single place with "IP-SCCP-like" logic that can make use of all "optimistic in-flight information" during a fixpoint iteration.
For now, we will have some IP-SCCP like logic rewritten in the Attributor framework, see for example D69605 <https://reviews.llvm.org/D69605> for liveness improvements. The conditional folding logic needs cleanup before I put them here but that should happen in the coming days as well. Now we want this because we want/need liveness information during the deduction and we can use other information that is deduced to improve the value simplification part (think constant propagation) and thereby liveness. One example would be capture information and memory access information based on liveness information which feeds back into the rest.

As an actually unrelated example, this code (https://godbolt.org/z/vP-vvM) works with the Attributor while IP-SCCP for some reason dislikes the dead `unknown(&X)` call. In the Attributor framework, it doesn't matter because the use of X is simply never shown to the relevant AAValueSimplify class as long as we assume it is dead. (All `Attributor::checkForAllXXXX(Predicate, ...)` methods simply "hide" dead code. XXXX can be CallSites, ReturnValues, Uses,....)

  static int X = 0;
  void unknown(int *);
  
  int foo(void) {
    if (X == 1)
      X = 2;  
    if (X == 2)
      unknown(&X);
    return X;
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69748





More information about the llvm-commits mailing list