Use getAnyExtOrTrunc helper instead of manually doing ext/trunc check. NFC.

[oota-llvm.git] / utils / lit / TODO

diff --git a/utils/lit/TODO b/utils/lit/TODO
index 419056a78f47baa83e449aabf1b83c61ac957885..90da327be9a217f9bf8ef553c10b8c1f3bb46f43 100644 (file)
--- a/utils/lit/TODO
+++ b/utils/lit/TODO
@@ -113,24 +113,49 @@ Infrastructure
   module. This is currently blocked on:
 
   * The external execution mode is faster in some situations, because it avoids
-    being bottlenecked on the GIL. We could fix this by moving to a good
-    multiprocessing model.
+    being bottlenecked on the GIL. This can hopefully be obviated simply by
+    using --use-processes.
 
   * Some tests in LLVM/Clang are explicitly disabled with the internal shell
     (because they use features specific to bash). We would need to rewrite these
     tests, or add additional features to the internal shell handling to allow
     them to pass.
 
+5. Consider changing core to support setup vs. execute distinction.
+
+  Many of the existing test formats are cleanly divided into two phases, once
+  parses the test format and extracts XFAIL and REQUIRES information, etc., and
+  the other code actually executes the test.
+
+  We could make this distinction part of the core infrastructure and that would
+  enable a couple things:
+
+  * The REQUIREs handling could be lifted to the core, which is nice.
+
+  * This would provide a clear place to insert subtest support, because the
+    setup phase could be responsible for providing subtests back to the
+    core. That would provide part of the infrastructure to parallelize them, for
+    example, and would probably interact well with other possible features like
+    parameterized tests.
+
+  * This affords a clean implementation of --no-execute.
+
+  * One possible downside could be for test formats that cannot determine their
+    subtests without having executed the test. Supporting such formats would
+    either force the test to actually be executed in the setup stage (which
+    might be ok, as long as the API was explicitly phrased to support that), or
+    would mean we are forced into supporting subtests as return values from the
+    execute phase.
+
+  Any format can just keep all of its code in execute, presumably, so the only
+  cost of implementing this is its impact on the API and futures changes.
+
 
 Miscellaneous
 =============
 
 * Move temp directory name into local test config.
 
-* Add --show-unsupported, don't show by default?
-
-* Optionally use multiprocessing.
-
 * Support valgrind in all configs, and LLVM style valgrind.
 
 * Support a timeout / ulimit.