Pass some decompose-complex-ops options in torch-to-iree

[zjgarvey]

Some problematic decompositions in torch-decompose-complex-ops are now disabled by default in the torch-to-iree pipeline. Also allows turning off all decompositions with an option.

[zjgarvey]

I've tried setting the default backendLegalOps in TorchToIREELoweringPipelineOptions, but I think there is something that goes wrong with checking against the default being modified when the option is a list. Maybe since the list doesn't have external storage, even if the contents are the "same" perhaps it is still is technically changed? I might have some confusion about where ireeCompilerSessionSetFlags gets the default values. I assume it gets them from the OptionsBinder, but I'm not sure how that relates to the default value in the TorchToIREELoweringPipelineOptions?

Anyway, this is failing iree/compiler/bindings/python/test/api/api_test because non-default args gotten from the compiler session is returning the backendLegalOps set, and I'm not really sure what the best way around this is without just hacking the option through as not an actual option. Honestly, anything is better than just decomposing all torch-ops without inspection.

[zjgarvey]

Okay, removing the backendLegalOps from the OptionsBinder seems to make that test pass.

The downside is that we can't configure the backendLegalOps set from the command line, but frankly I'm okay with that. The only route we are taking with this option is to convert torch to linalg, so the list of backendLegalOps should be standardized anyway.

[ScottTodd]

Why is this an option at this level? Shouldn't this be set locally where it is used? I can't quite tell from the PR context if this is a user-facing CLI option, but I wouldn't want any user to need to pass a list of "legal" ops to the compiler - the compiler should be able to make that determination on its own.

Also remember: IREE can multi-target, so any decisions made at the input pipeline level must be "backend"-agnostic, where "backend" here means https://github.com/iree-org/iree/tree/main/compiler/plugins/target (cuda, llvm-cpu, metal-spirv, rocm, vmvx, vulkan-spirv, etc.)

[zjgarvey]

That's a good point.

My understanding is that this is only a user-facing CLI option for iree-opt --torch-to-iree, and not for iree-compile. Do you think I shouldn't pass the backend-legal-ops list as an option at all? I'm totally fine with that.

[ScottTodd]

My understanding is that this is only a user-facing CLI option for iree-opt --torch-to-iree, and not for iree-compile.

I should be able to tell from reading the code... but do the new options appear in iree-compile --help?

Do you think I shouldn't pass the backend-legal-ops list as an option at all? I'm totally fine with that.

A developer option for debugging could be fine, if you or others working on the Torch / ONNX lowerings would use it. I wouldn't do the plumbing for an option unless you have a specific use in mind though. Each branch and option in code takes effort to support.

[zjgarvey]

It took me a while to figure this out from the API. The option torch-use-decompose-complex-ops does appear for iree-compile, since is it bound to the OptionBinder, but the backendLegalOps is not configurable from iree-compile, since I am not binding that option.

The signature of create<passname> is a bit restrictive, so I am really only passing this option to be able to pass the list of backendLegalOps from PluginRegistration.cpp into the torch-to-iree pipeline.

Let me think of some ideas on how to best clean this up.

[zjgarvey]

@ScottTodd Can you take a look at the changes to see if it makes more sense?

I need the backendLegalOps list in two places, and I remember their being some llvm convention on not using global static variables https://llvm.org/docs/CodingStandards.html#do-not-use-static-constructors. So I opted to have a getter function that just returns the list. It will require reconstructing it each time on a function call, but this was the best I could think of to avoid duplicating the hard-coded list (don't want to have to edit it in two places if we need to add another op).

[ScottTodd]

Another way to structure that might be to first run a common decompose ops pass / pipeline then add the mlir::torch::Torch::createTorchOnnxToTorchBackendPipeline and/or TorchInput::createTorchToIREEPipeline. That way there would be only one location that needs the list.

[zjgarvey]

Yeah, I frankly don't know what the purpose of decompose complex ops in the torch-to-iree pipeline is, but I'd like to keep the torch-to-iree pipeline stable to avoid possible regressions unrelated to ONNX for now.

[ScottTodd]

Okay as-is for now. Could explore reordering the pipelines to reduce duplicate code.