Disable TORCH_MLIR_ENABLE_JIT_IR_IMPORTER by default

[AmosLewis]

Temporary fix for Disable TORCH_MLIR_ENABLE_PYTORCH_EXTENSIONS #3654

Disable TORCH_MLIR_ENABLE_JIT_IR_IMPORTER by default

• Only enable it in CI for update_abstract_interp_lib.sh and update_torch_ods.sh usage.

TODO:

• Deeper doc change [Doc] Deeper doc change after disable TORCH_MLIR_ENABLE_JIT_IR_IMPORTER #3696
• Pure python verion of torch_ods_gen.py and abstract_interp_lib_gen.py Pure python verion of torch_ods_gen.py and abstract_interp_lib_gen.py #3695

[stellaraccident]

We also need to revise some docs:

https://github.com/llvm/torch-mlir?tab=readme-ov-file#all-the-roads-from-pytorch-to-torch-mlir-dialect : The graphic can either be updated or removed. We should reference FX and ONNX as the entry points. MHLO -> StableHLO

Remove the Demos section (https://github.com/llvm/torch-mlir?tab=readme-ov-file#demos) as it refers only to demos that are now disabled by default. In its place we can do something like:

## Using torch-mlir

Torch-MLIR is primarily a project that is integrated into compilers to bridge them to PyTorch and ONNX. If contemplating a new integration, it may be helpful to refer to existing downstreams:

* IREE (link)
* Blade (link)
* Reference CPU runner (local docs)

While most of the project is exercised via testing paths, there are some ways that an end user can directly use the APIs without further integration:

* (see example of FX import)
* (see example of ONNX import)
* etc

While editing this, we should also drop the Meetings section as I don't think those are running anymore.

There are some deeper doc changes that would be useful to scrub but we can do those once fixing the front door README.

Fine to make the doc changes in a separate PR, but let's not submit this patch without at least a link to the PR with pending doc changes.

[stellaraccident]

Updates lgtm

[qingyunqu]

I have two points of concern on this PR:

1. It seems that ci doesn't test fx_importer with tosa or stablehlo backend.
2. GeneratedTorchOps.td was generated depend on jit_ir_importer now. What's the future plan?
   @AmosLewis @stellaraccident

[qingyunqu]

Sorry, I see that #3698 add test on stablehlo backend.

[stellaraccident]

The stablehlo test diffs were an omission, which I think now is resolved. I don't have anyone working with me who uses the TOSA side and need contributors there to configure things properly.

Regarding the ODS issues, Chi is working on a pure python solution for this. The original idea was to do that first but the situation with the c++ extension failing for users (and breaking the whole project) was becoming critical: we had a comparative spike of issue reports over the last week and my team was not able to identify any fixes. In addition, these code paths were implicated in blocking a recent llvm upgrade, consuming multiple engineers on a tangent for a week (llvm/llvm-project#105656 (comment)).

We just don't have any contributors who can maintain this code anymore (and it is the single flakiest thing in the project), and we've been saying that it is deprecated since the beginning of the year/the day will come we can't keep it running. My team is at that point, and we can't spend any more time keeping investing in it. We will continue with a fix to make the ODS generation pure python.

I see you've posted on the discourse thread. Let's discuss options there.

[sjarus]

Sorry for the late comment @stellaraccident - I didnt see this as I wasn't tagged. Arm can step in around TOSA - we are actively working on it and test all targets locally, with our priority being the fx_importer_tosa one that has a significantly better pass rate and rising.

PyTorch 1.0 JIT import isn't really priority, and ideally we'd focus on fx_importer_tosa and onnx_tosa . @mgehre-amd was a user of the PT1 TOSA import path - has that changed ?

[mgehre-amd]

We are currently still using make_fx_tosa and are looking to migrate to fx_importer_tosa.