sym_max support in ExecuTorch

[guangy10]

🐛 Describe the bug

Hit this issue when I was debugging the gemma-3 error in optimum-executorch (CI link).

Upon checking the complained op_overload, the function object is actually a sym_max which is introduced via this line

https://github.com/huggingface/transformers/blob/1d45d90e5d1552eccb6d8cc9b7bba283ccefb808/src/transformers/cache_utils.py#L1725-L1732

        if self.is_sliding[layer_idx]:
            query_length = cache_position.shape[0]
            ...
            local_mask_kv_length = max(query_length, self.sliding_window)
            return local_mask_kv_length, local_mask_kv_offset

in the upstream transformers in the HybridCache class, which is expected as now we set the cache_poistion dim to be dynamic in huggingface/optimum-executorch#73.

The export works fine to have the sym_max in the exported graph (test_hybrid_cache_exportability passed in the transformers), but when further lowering the graph to executorch, the call to_executorch failed.

On chatting with @kimishpatel , it seems like we are missing implementation for sym_max as an op.

Versions

trunk

[JacobSzwejbka]

I think this is a good issue for new contributors. Its pretty simple I can help anyone who signs up.

https://github.com/pytorch/executorch/blob/main/kernels/prim_ops/register_prim_ops.cpp -> cpp code
https://github.com/pytorch/executorch/blob/main/exir/passes/executorch_prim_ops_registry.py -> python code

You pretty much should just need to add an impl to both of those.

[kimishpatel]

I have fixed this actually. I was using this for giving claude code another chance. It didnt do that well.