Upgrading llvm and stablehlo hash

[christopherlmunoz]

llvm: b270525f730be6e7196667925f5a9bfa153262e9
stablehlo: 459e481b

[hamptonm1]

Looks good but I had one comment

[hamptonm1]

@jorickert This update was made due to the following error message :

/Users/christophermunoz/repos/cmunoz1/onnx-mlir/test/mlir/conversion/onnx_to_tosa/NN/AveragePool.mlir:139:8: error: 'tosa.pad' op operand #1 must be 1D tensor of 32-bit signless integer or 64-bit signless integer values, but got 'tensor<4x2xi64>'

Just want to make sure this update is fine.... I am not too familiar with TOSA, so asking just in case.

[hamptonm1]

LLVM made some updates to TOSA as shown in this PR: llvm/llvm-project#122547

[AlexandreEichenberger]

@hamptonm1 thanks for reviewing this, I will assume that you will approve it once you are satisfied with the answers to your question.

[hamptonm1]

@AlexandreEichenberger @tungld I think Chris mentioned he was working with you guys to resolve the round backend test but if we can not get it resolved, would it be okay to comment it out and open an issue to fix it later on?

----------------------------- Captured stderr call -----------------------------
failed to legalize operation 'vector.shape_cast'
=========================== short test summary info ============================
 Release/test.py::OnnxBackendNodeModelTest::test_round_cpu - subprocess.Calle...

[christopherlmunoz]

@AlexandreEichenberger @tungld I think Chris mentioned he was working with you guys to resolve the round backend test but if we can not get it resolved, would it be okay to comment it out and open an issue to fix it later on?

----------------------------- Captured stderr call -----------------------------
failed to legalize operation 'vector.shape_cast'
=========================== short test summary info ============================
 Release/test.py::OnnxBackendNodeModelTest::test_round_cpu - subprocess.Calle...

I spoke with Tung again. Created issue #3068 and commented out tests. Will continue the investigation and work to resolve this asap.

[hamptonm1]

@christopherlmunoz Before I approve, please reach out to @jorickert via slack to answer the question above. I want to make sure the TOSA updates are fine before merging in.

[AlexandreEichenberger]

I spoke with Tung again. Created issue #3068 and commented out tests. Will continue the investigation and work to resolve this asap.

I can look at that issue, since it impacts quantization operations. Can we quantize benchmarks without this fix? If we cannot, then this PR should not go in.

[jorickert]

LGTM, tosa.pad will need to be changed again when the LLVM bump containing llvm/llvm-project#123133 lands

[jorickert]

We could use F16 for here if the datatype of the conv is F16, but using F32 for the accumulator should be generally safe

[christopherlmunoz]

Hi @jorickert, would you prefer something like this? Otherwise, I'm happy to keep it the same.

Type convType = (resultType.isF16()) ? rewriter.getF16Type() : rewriter.getF32Type();
TypeAttr accType = mlir::TypeAttr::get(convType);`

[jorickert]

Yes, I think this would be better

[hamptonm1]

@AlexandreEichenberger Were you able to resolve the backend test? I know you wanted to fix that before merging this PR.

[AlexandreEichenberger]

Please go ahead with this, if the path that generates the error listed in #3068 is disabled. I.e. not just the test, but the options that generates the offending code.