fix(ONNX): avoids resizing unsupported dimensions

[bjacobgordon]

Prevents #3453

[zjgarvey]

I think the main structural question is about the need for adding the BaseTensorType method. If it were useful elsewhere (I have some doubts, since we would need to know too much about the two tensor shapes prior to using it- namely that they are present, and they have the same rank), I would consider keeping it; however, the code is simplified here by not using it, and I suspect that the same would be true in other circumstances where it might be used.

[zjgarvey]

Sorry for the misdirect earlier, we need to perform the runtime asserts on the scales or sizes values instead of sizes, since we will not have access to the correct output sizes ahead of time.

[IanWood1]

I think the renaming of loc -> opLocation should probably be split into a different PR so it can be reviewed separately, it adds ~600 lines of changes that aren't directly related to the functional changes. It would help to keep this PR focused and easier to review.

[bjacobgordon]

Okay, @zjgarvey, I think we're in business! Got green on the CI a few hours ago. Just wrapped up self-review.

I'm guessing now we'll:

• discuss how the diffs might need to change
• finalize those changes
• discuss which chunks of commits need to be in the PR stack
  Something like that?

I kept the commits atomic and ordered such that it's easier to propagate changes to the head of the branch in case an earlier commit needs to be inserted/tweaked/excised.

Let me know what you think!

[zjgarvey]

Okay, @zjgarvey, I think we're in business! Got green on the CI a few hours ago. Just wrapped up self-review.

I'm guessing now we'll:

* discuss how the diffs might need to change

* finalize those changes

* discuss which chunks of commits need to be in the PR stack
  Something like that?

I kept the commits atomic and ordered such that it's easier to propagate changes to the head of the branch in case an earlier commit needs to be inserted/tweaked/excised.

Let me know what you think!

Nice!

At least for now, please exclude any commits which involve style changes not directly related to the fix content. E.g. widespread enforcement of naming preferences like the loc -> opLocation should be factored out into a separate PR as @IanWood1 suggested.

[bjacobgordon]

Hey, @zjgarvey, I've rebased onto main!

To make it easier for you to re-review, I could segment this PR into a stack of 3 PRs. It'll be really easy; the commits are already primed for it!

Would you like me to do that for you?

[zjgarvey]

Hey, @zjgarvey, I've rebased onto main!

To make it easier for you to re-review, I could segment this PR into a stack of 3 PRs. It'll be really easy; the commits are already primed for it!

Would you like me to do that for you?

No, this change looks manageable and self-contained.

I'll review a bit more carefully today.

[zjgarvey]

Looks good!

[ScottTodd]

FYI this appears to have caused some test failures downstream in the IREE project on iree-org/iree#19976. I did not bisect to this specific change or line of code, but this looked most relevant. These are the logs: https://github.com/iree-org/iree/actions/runs/13292751088/job/37117771168?pr=19976#step:8:50

 _ IREE compile and run: test_resize_downsample_scales_cubic_align_corners::model.mlir::model.mlir::cpu_llvm_sync _
[gw2] linux -- Python 3.11.11 /home/runner/work/iree/iree/venv/bin/python
Error invoking iree-compile
Error code: 1
Stderr diagnostics:
<unknown>:0: error: failed to legalize operation 'torch.constant.float'
<unknown>:0: note: see current operation: %6 = "torch.constant.float"() <{value = 1.000000e+00 : f64}> : () -> !torch.float


Stdout diagnostics:


Test case source:
  https://github.com/iree-org/iree-test-suites/blob/main/onnx_ops/onnx/node/generated/test_resize_downsample_scales_cubic_align_corners

Input program:
```
module {
  func.func @test_resize_downsample_scales_cubic_align_corners(%arg0: !torch.vtensor<[1,1,4,4],f32>, %arg1: !torch.vtensor<[4],f32>) -> !torch.vtensor<[1,1,3,3],f32> attributes {torch.onnx_meta.ir_version = 9 : si64, torch.onnx_meta.opset_version = 19 : si64, torch.onnx_meta.producer_name = "backend-test", torch.onnx_meta.producer_version = ""} {
    %none = torch.constant.none
    %0 = torch.operator "onnx.Resize"(%arg0, %none, %arg1) {torch.onnx.coordinate_transformation_mode = "align_corners", torch.onnx.mode = "cubic"} : (!torch.vtensor<[1,1,4,4],f32>, !torch.none, !torch.vtensor<[4],f32>) -> !torch.vtensor<[1,1,3,3],f32> 
    return %0 : !torch.vtensor<[1,1,3,3],f32>
  }
}

```

Compiled with:
  cd /home/runner/work/iree/iree/iree-test-suites/onnx_ops/onnx/node/generated/test_resize_downsample_scales_cubic_align_corners && iree-compile model.mlir --iree-hal-target-backends=llvm-cpu --iree-input-demote-f64-to-f32=false -o model_cpu_llvm_sync.vmfb

By default, IREE demotes f64 to f32 as 64 bits of precision is rarely needed in ML models and many hardware targets either do not support f64 at all or support it with significant performance penalties. The tests there do override that default by setting --iree-input-demote-f64-to-f32=false though.

Is f64 needed here, or would f32 work? I see lots of uses of f64 in this file 🤔

[ScottTodd]

More context: some of the tests in the ONNX test suite require f64, which is why we run the tests without f64 to f32 demotion: iree-org/iree#18111.

[zjgarvey]

We dont need f64, this is a small bug with the changes. Will post a quick fix in a minute.

[bjacobgordon]

If I remember correctly when writing this, using f32 for scaleIdentity caused a test case or two within torch mlir to fail.

@zjgarvey Any insights here?

[zjgarvey]

Wait, F64 is the correct attr type for constant float ops. I'll take a look at the test failures.

[zjgarvey]

Looks like a simple issue. AtenEqFloatOp doesn't have a lowering, but it should be easy to add. I'll post a PR shortly.

[zjgarvey]

I re-ran the iree tests with #4022

The failing tests go back to passing with that change.

[ScottTodd]

Nice, thanks!