Long story short, after https://github.com/apache/tvm/pull/8509 we see a lot of floating point models crash during compilation for Hexagon. On Hexagon (downstream) we use the mixed-precision pass to convert float32 data to float16. Float16 constants are not supported by constants in TIR and compilation aborts.
Longer story... The relay pass `FuseOps` is the one that can extract constants out of expressions, and replace them with parameters. Constants that are not parameters cannot have type float16, because that type is not supported by current TIR code (for embedded constants). If this extraction doesn't happen, compilation will abort if a float16 constant is found in TIR. After commit b5f1dabce4 (PR8509), `FuseOps` will no longer extract constants if the build target has `link_params` set to true. This can be, at least in theory, overridden by pass context flag `relay.FuseOps.link_params`, but there is an issue. The problem is as follows: * The `FoldConstant` pass runs, and it creates a fresh `PassContext`, without any config flags in it. It also uses the "cpu" target instead of the actual one for `CompilationConfig`. * During execution, `FoldConstant` will invoke relay interpreter's function `Eval`, which initiates a series of relay passes, including `FuseOps`. * `FuseOps` gets `link_params` value from `IRModule`'s attribute `Executor`, which is still consistent with the actual target. If the original target has `link_params = 1`, it will take effect regardless of any flags added to PassContext at the `relay.Build` time. It seems like `FuseOps` should be getting settings consistent with the CPU target that `FoldConstants` created, instead of using `Executor` from `IRModule`. This difference may have further consequences if passes executed during `FoldConstants` consult the executor for more information. Any thoughts? --- [Visit Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/0b6ce7e6937a48ba45f2697ea4cb66f7a2310582dd0902276e7f45fc523f64be).
