[MLIR] Print more user-friendly error message when generating local reproducer and threading is enabled #144905
Conversation
…er and threading is enabled fixup: remove module in test
|
@llvm/pr-subscribers-mlir-core @llvm/pr-subscribers-mlir Author: Artemiy Bulavin (abulavin) ChangesCurrently if you run However, according to the local reproducer generation documentation, disabling threading is required in order to generate a local reproducer. The current error message suggests this is a bug despite the MLIR documentation stating that this is a necessary constraint. Not disabling threading in this scenario is a user error so I have changed the error to be a pass manager An error is still printed but not in the same way that asks the user to file a bug report. I think this should help prevent any future confusion, such as what may have arised here #128344 Unit test added. Full diff: https://github.com/llvm/llvm-project/pull/144905.diff 2 Files Affected:
diff --git a/mlir/lib/Pass/PassManagerOptions.cpp b/mlir/lib/Pass/PassManagerOptions.cpp
index dd119a75f4069..305bf72bb4799 100644
--- a/mlir/lib/Pass/PassManagerOptions.cpp
+++ b/mlir/lib/Pass/PassManagerOptions.cpp
@@ -146,6 +146,14 @@ LogicalResult mlir::applyPassManagerCLOptions(PassManager &pm) {
if (!options.isConstructed())
return failure();
+ if (options->reproducerFile.getNumOccurrences() && options->localReproducer &&
+ pm.getContext()->isMultithreadingEnabled()) {
+ emitError(UnknownLoc::get(pm.getContext()))
+ << "Local crash reproduction may not be used without disabling "
+ "mutli-threading first.";
+ return failure();
+ }
+
// Generate a reproducer on crash/failure.
if (options->reproducerFile.getNumOccurrences())
pm.enableCrashReproducerGeneration(options->reproducerFile,
diff --git a/mlir/test/mlir-opt/local-reproducer-with-threading.mlir b/mlir/test/mlir-opt/local-reproducer-with-threading.mlir
new file mode 100644
index 0000000000000..10ebaed1c63da
--- /dev/null
+++ b/mlir/test/mlir-opt/local-reproducer-with-threading.mlir
@@ -0,0 +1,5 @@
+// Test that attempting to create a local crash reproducer without disabling threading
+// prints an error from the pass manager (as opposed to crashing with a stack trace).
+
+// RUN: mlir-opt --mlir-pass-pipeline-local-reproducer --mlir-pass-pipeline-crash-reproducer=%t 2>&1 %s | FileCheck %s
+// CHECK: error: Local crash reproduction may not be used without disabling mutli-threading first.
|
|
@joker-eph @amirBish Thanks both. I don't have write access, please could this be merged for me? |
Currently if you run
mlir-optwith--mlir-pass-pipeline-local-reproducer--mlir-pass-pipeline-crash-reproducerand don't provide--mlir-disable-threadingyou will get an LLVM error printed that suggests this is a bug and needs to be reported to LLVM. For example:However, according to the local reproducer generation documentation, disabling threading is required in order to generate a local reproducer. The current error message suggests this is a bug despite the MLIR documentation stating that this is a necessary constraint. Not disabling threading in this scenario is a user error so I have changed the error to be a pass manager
emitErrorto reflect this.An error is still printed but not in the same way that asks the user to file a bug report. I think this should help prevent any future confusion, such as what may have arised here #128344
Closes #128344
Unit test added.