Yukio Siraichi

I investigated this problem a bit. It was strange that, in the `UpsampleBilinear::Lower` function, `operand(0).node` is of type bf16, but `ShapeHelper::ShapeOfXlaOp(input)` is of type fp32. Looking at the HLO representation...

This is the only model that runs into this specific issue. There are, however, a similar issue with `hf_GPT2`: #6521.

Here's an odd thing I've noticed: there's some compilation taking place in the second iteration: | iteration | time (s) | CompileTime number | |--------------|------------|----------------------------------| | 1 | 887 |...

That's odd. Last I tried (a8b27eb1c) they were still passing on inductor. `python xla/benchmarks/experiment_runner.py --no-resume --suite-name torchbench --repeat 2 --accelerator cuda --test eval --xla None --dynamo inductor` I will try...

Oops. I think I misinterpreted your question. So, on torchbench they are skipped only if we try to [export those models]( https://github.com/pytorch/pytorch/blob/c170fbd309a5006aa2e01daa543e7136bb4067ba/benchmarks/dynamo/common.py#L3635-L3642). Otherwise, they should pass (I think).

I have looked into this issue, and contrary to what [@zpcore found](https://github.com/pytorch/xla/issues/5967#issuecomment-1903373265), I successfully run with `dynamo+openxla` both these benchmarks by increasing `XLA_COMPILATION_CACHE_SIZE=2048`. It could, however, still timeout, depending on...

`opacus_cifar10` training is still failing with this issue.

Both `hf_GPT2` and `hf_GPT2_large` seem to be failing with this same error in the following cases: - Non-dynamo: inference - Dynamo: inference + training

Here's an odd thing I've noticed: there's some compilation taking place in the second iteration: | iteration | time (s) | CompileTime number | |--------------|------------|----------------------------------| | 1 | 440 |...

Yes. You are right. The `SemanticVerifierPass` was mostly a "sanity checker" for messing with qubit mappings. So, in summary, it verifies that two circuits are semantically the same iff: >...