Standardize naming

[sdasgup3]

Request description

The need for such a ticket initiated in #335 (comment).

Let us use this ticket to collect opportunities to apply uniform naming across various StableHLO artifacts like the entities in the ODS.

From #335 (review)

... ensure that: 1) the opset has uniform naming style, 2) all C++/Python breaking changes related to naming are done at once instead of spread over weeks or months of breakages.

[ghpvnist]

Some ops have inconsistent naming with our standard e.g. using "output" instead of "result" in the ODS. The spec, ODS example, and pretty-print currently defaults to "result" even if the ODS name is "output". These ops are (in no particular order):

• Constant
• Iota
• IsFinite
• DynamicIota
• CreateToken
• BatchNormTraining
• DynamicBroadcastInDim
• DynamicReshape
• RngBitGenerator
• ReducePrecision

[burmako]

Looks like log_plus_one is a misnomer. Unlike exponential_minus_one, which computes exp(x) - 1, this op computes log(1 + x), so I think that it should be renamed to log_one_plus, consistently with the short name of the op which is log1p (cf. expm1).

[burmako]

Some more ideas for standardizing names:

1. input vs operand (output vs result already called out above).
2. Consistent use of singulars and plurals (e.g. TupleOp::val should be vals, etc).
3. IotaOp::iota_dimension (and multiple similar cases) vs ReverseOp::dimensions.
4. Specifying the "result" name explicitly vs relying on TableGen to provide name it implicitly.
5. Same thing as above but for derived unary and binary ops.
6. IsFiniteOp:x/y - can we use standard names?
7. CompareOp::compare_type - why not comparison_type, given that this is how the enum is called?
8. CholeskyOp::a - can we use standard name?
9. DotGeneralOp::dot_dimension_numbers vs ConvolutionOp::dimension_numbers.
10. CompareOp::comparison_direction/FftOp::fft_type/etc vs just direction/type/etc.
11. Compare names with HLO and see if that exposes more inconsistencies. Would be good to align with HLO if possible.
12. Compare op names and op mnemonics. E.g. why SinOp has the "sine" mnemonic? Can we have op names and op mnemonics be the same (modulo case).

[ghpvnist]

The mnemonic for CrossReplicaSumOp is cross-replica-sum, which is not consistent with other mnemonics which uses underscore case: cross_replica_sum. This needs to be changed in status.md, StablehloOps.td, and other related files (e.g. including tests/mlir files).

[burmako]

Naming affects serialization, and this changes the project for this ticket from the P1 priority Public API to the P0 priority Specification Compliance. We'll need to sort this out before the release of v1.0.

[ghpvnist]

Another instance where naming can improve in TupleOp.

[ghpvnist]

Instances here and here in collective_broadcast where change in attribute names are suggested.