Adding rounding_mode support to convert() HLO

[Marcello Maggioni]

Hello,

I write to gauge the opinion from folks about adding a "rounding_mode" attribute to the convert() HLO.

The motivation for this is that currently there's no way to communicate to the XLA compiler what kind of rounding to perform while doing a FLOAT->INT conversion.

Currently backends do a bit what they want, but my understanding is that if a backend picks one kind of rounding for the conversion (say Round To Zero) it sticks with that choice for all it's subtargets.

It's worth noting that HLO_EVALUATOR seems to be using Round To Zero when performing it's evaluations. (for tests)

Some sub-architectures of a specific platform might be faster in doing conversions using another kind of conversion type (say RTNE), but there's no way to make use of that right now.

If we added a "rounding_mode" attribute to convert() we could specify such information.

We could have a few options like:

ROUND_DEFAULT -> Just do what you do today, probably RTZ

ROUND_FAST -> Pick whatever is faster for the hardware

ROUND_NEAREST_NE -> Round to nearest ties to even

ROUND_NEAREST_AFZ -> Round to nearest ties away from zero

FAST would allow to communicate that we the user doesn't care about any specific kind of rounding. Just get the job done as fast as possible. (FAST might still break compatibility strictly speaking with hlo_evaluator, but it might not be expected in the first place and one might want to give an errorspec even for integers).

A second solution to the problem potentially is to add instead a specialized "fast convert" HLO (something like quantize() or convert_fast()) that allows the target to do as it please. It wouldn't allow for more flexibility in choosing different rounding algorithms other than the default.

Third solution would be to leave this unspecified and just let the backends do whatever they prefer like it is today and not give people ways to control these details. The backend though might not have ways to distinguish converts where rounding matters vs those where it doesn't. (Not sure if this might ever be a problem).

Wondering what people thought and if anybody else might have need for something like this.

Thanks,
Marcello

[George Karpenkov]

Sounds reasonable to me, also cf. b/138669433: currently in some cases we even trigger UB when doing a convert to integer (on the interpreter and on CPU IIRC)

--
You received this message because you are subscribed to the Google Groups "XLA development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xla-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xla-dev/4d722fd3-b61c-42cd-ac30-33ae9926e5b9n%40googlegroups.com.

[Marcello Maggioni]

Thanks George,

I'll send the CL then. Talking with David we might want to hold on the "_FAST" for now and put the burden on the user instead to pick the fastest version. (and leave the can of worms of dealing with things that the users didn't expect for another time).

Marcello