[DEBUG] Only print out diagnostic messages if an environment variable is set

[gflegar]

This prevents crashes in test_core.py due to too many diagnostics emitted in llvm/llvm-project#78228 It should also speed up compile times, as we can use multithreading, and avoid handling diagnostic messages.

[ThomasRaoux]

Thanks!

[jlebar]

After some debugging on our side, I am not sure that this patch does what was intended.

• If you don't call context->getDiagEngine().registerHandler([](Diagnostic &diag) {, MLIR seems to register one by default that prints to stdout or stderr, which is identical to what we do when we do register a handler, so this has no effect either way.
• context->printOpOnDiagnostic(true); is the default, so this has no effect either way.
• context->printStackTraceOnDiagnostic(true); is not the default, but setting it doesn't seem to have an effect as far as we can tell.
• We observe that the diagnostics printed out when Triton fails seem to be identical with and without this patch (with no envvar set).

Therefore the only effect this patch seems to have is enabling multithreading unless you set the new envvar.

We are happy that the diagnostics are the same with and without this patch, at least in the way we use Triton. If you want to make a patch to actually print fewer diags, that should probably be disabled by default, and you can enable it on your side.

[gflegar]

Thanks for looking into it. That's quite interesting, I just double checked if I missed the printouts in our output after the patch, and I can clearly see them before it, and they disappeared afterwards.

I see two possibilities why that happened: either it's because we are using a newer version of LLVM, and the default MLIR behavior changed (you could try patching in #3150 to try it out), or it has something to do with how the pytest runner works (it's a bit of a mystery to me TBH) - e.g., maybe enabling multithreading again somehow prevents the crash, and pytest only prints out stdout / stderr if the test fails.

[gflegar]

According to the latest comments in #3150 it seems that this is doing something even upstream with a newer version of LLVM.