Add SimplifiedLayerNormToRMSNorm surgery

[unnim-qti]

Describe your changes

Checklist before requesting a review

• Add unit tests for this change.
• Make sure all tests can pass.
• Update documents if necessary.
• Lint and apply fixes to your code by running lintrunner -a
• Is this a user-facing change? If yes, give a description of this change to be included in the release notes.

(Optional) Issue link

[xiaoyu-work]

@unnim-qti can you please update this PR? We are going to release new Olive version this Friday and this PR will be included

[justinchuby]

Why not make this a rewrite rule, out of curiosity?

[unnim-qti]

Why not make this a rewrite rule, out of curiosity?

I considered a rewrite rule, but this transform isn’t purely structural.

• It has opset‑dependent ReduceMean semantics, handles two operator variants and requires conditional rewiring of an optional second output with ValueInfo preservation, which is cumbersome to express in a pattern rewrite.
• A ProtoSurgeon was therefore a cleaner and safer fit.

[justinchuby]

Handling value infos and optional output handling should be straightforward with the onnxscript rewriter. I wonder if you saw any blockers?

[unnim-qti]

I didn’t see any hard blockers in the rewriter, but I followed the existing pattern SimplifiedLayerNormToL2Norm, which use ProtoSurgeon to handle variant‑specific wiring, and optional outputs explicitly. Given that precedent and the comparable complexity here, I kept this transform in the ProtoSurgeon style for the consistency.

[unnim-qti]

Handling value infos and optional output handling should be straightforward with the onnxscript rewriter. I wonder if you saw any blockers?

can you review the changes and initiate the pending checks.

[qti-mattsinc]

@unnim-qti, this causes an error with fp16 activations, since eps_const is always fp32 in this surgery:

Type Error: Type parameter (T) of Optype (Add) bound to different types (tensor(float16) and tensor(float) in node (/model/layers.0/input_layernorm/LayerNorm_AddEps).

We should be able to get the datatype for epsilon from the type of ln_input.

Similar situation with pow_const, although Pow is allowed to have inputs of different types, so it's not a hard error unlike for Add.

[unnim-qti]

@qti-mattsinc , Thanks for pointing this out — I’ve updated the surgery to assign epsilon (and pow_const) to match the ln_input datatype, which resolves the FP16 activation type mismatch in the Add node.

[unnim-qti]

@jambayk , Could you please re‑initiate the rebuild? The docs build failed due to a 404 Client Error.