Audit correspondence between the spec and VHLO

[burmako]

Before we start providing compatibility guarantees for VHLO, it sounds like a good idea to go through all ops in the spec and see where the correspondence between the spec and VHLO is not 1:1. All these cases should be documented in Frontend Contract tickets.

[burmako]

Documenting the current progress of the audit:

1) Attributes: #1188, #1190, #1191, #1192, #1194 and #1195 - these pull requests have made significant progress with aligning VHLO attributes with the StableHLO spec. Remaining work:

• Decide on modelling buffer donation #740 (ArgResultAliasAttr/OutputOperandAliasAttr).
• Consider removing sentinel enum values from VHLO #1186 (VHLO_COMPARISON_TYPE_NOTYPE, VHLO_CUSTOM_CALL_API_VERSION_UNSPECIFIED and VHLO_TRANSPOSE_INVALID).
• Spec and implement Module/Func/Call/Return ops #425 (DictionaryAttr/TypeAttr).
• Spec EnumConstant #848 (The entirety of VhloEnums.td).
• Write a dynamism RFC #8 (TypeExtensionsAttr).

2) Types: #1189 makes some refactorings to align VHLO types with the StableHLO spec. Remaining work:

• Write a dynamism RFC #8 (IndexType, RankedTensorType::encoding, UnrankedTensorType, Witness).
• Spec quantization #588 (UniformQuantizedType).

3) Operations: #1184 streamlines VhloOps.td, ordering the ops alphabetically to simplify comparison with the StableHLO spec. Based on this work, I should be able to complete the audit shortly.

[burmako]

#1184 completes the audit of the correspondence between the spec and VHLO. Remaining work:

• Consider moving "Not in HLO" ops to CHLO #3 (BroadcastOp, CreateTokenOp, CrossReplicaSumOp, DotOp, EinsumOp, TorchIndexSelectOp, TraceOp, UnaryEinsumOp).
• Decide on layouts #629 (CustomCallOp, InfeedOp, OutfeedOp).
• Decide on modelling buffer donation #740 (CustomCallOp).
• Decide on speccing api_version of CustomCallOp #1187 (CustomCallOp).
• Spec and implement Module/Func/Call/Return ops #425 (CallOp, FuncOp, ReturnOp).
• Spec quantization #588 (UniformDequantizeOp, UniformQuantizeOp).
• Write a dynamism RFC #8 (ComputeReshapeShapeOp, CstrReshapableOp, DynamicBroadcastInDimOp, DynamicConvOp, DynamicGatherOp, DynamicIotaOp, DynamicPadOp, DynamicReshapeOp, RealDynamicSliceOp).

Overall, the audit confirms that we are almost ready for StableHLO v0.9 (no unexpected issues that could become a blocker), and that the plan for StableHLO v1.0 makes sense (all todos except one - #1187 - introduced during the audit are known issues which are part of the Frontend Contract workstream).

Next steps: there are two time-sensitive questions about the VHLO opset to resolve before releasing StableHLO v0.9: #1056 and #1183. Both of these tickets affect a large area of VHLO, so it would be very good to fit them in while we still don't provide any compatibility guarantees for VHLO.

There is another ticket with a huge blast radius - #351 - but we will need quite a bit of time to form a plan of action for this one and to prepare our users, so fitting it into the v0.9 timeframe will be infeasible.