[PATCH] D59918: [Attributor] Pass infrastructure and fixpoint framework

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 28 20:27:30 PDT 2019

hfinkel added inline comments.

Comment at: llvm/include/llvm/Transforms/IPO/Attributor.h:25
+// information to other abstract attributes in-flight but we might not want to
+// manifest the information. The Attributor allows to query in-flight abstract
+// attributes through the `Attributor::getAAFor` method. If used by an abstract
An example would be useful here for explaining the abstract attributes "(e,g,, something)".

Comment at: llvm/include/llvm/Transforms/IPO/Attributor.h:48
+// find another justification or limit the optimistic assumes made.
+// Change is the key in this framework. Until a state of no-change, thus a
I'm not yet sure how to think about this. Many current attributes are derives with the help of LLVM utility functions which walk use-def chains, etc. How can an attributor use those utilities and know on what else it depends?

Or are we going to enhance all utilities to return an optional dependency vector or similar?

Or is the idea that we don't change the IR until the end, so all such utilities see only pessimistic information?

Comment at: llvm/lib/Transforms/IPO/Attributor.cpp:365
+  // re-initialization of the arguments. This re-run should not result in an IR
+  // change. Though, the (virtual) state of attributes at the end of the re-run
+  // might be more optimistic than the known state or the IR state if the better
This is true even if we did't reach the fixpoint and has to reset some attributes to their pessimistic state?

Comment at: llvm/lib/Transforms/IPO/Attributor.cpp:401
+      break;
+    }
+    if (IsInterestingOpcode)
Are there supposed to be some other cases here?

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list