Triton type promotion semantics for floating dtypes are very non-intuitive

[lezcano]

I recently wrote some documentation describing the triton promotion semantics. It turns out that part of it was not entirely correct. The reality is much murkier.

The type promotion semantics around fp16 and bf16 between them and fp8 dtypes are incredibly odd. We perform with the following precedence:

1. If the operation is a division or a mod, and an input is of fp16 or bf16, the result is of type fp32 (??!!). e.g. fp16 / fp16 = fp32, bf16 % bf16 = bf16.
2. If both inputs are of the same dtype, then perform the computation in that dtype (fair)
3. If you mix fp16 and bf16, it will return fp16 (fair)
4. If you mix bf16 and any fp8 it will return fp32 ??!!

I propose changing them (the semantics of binary ops of floating types) to:

1. Preserve dtype If both inputs are of the same dtype, then perform the computation in that dtype. With this fp16 / fp16 = fp16 as expected. We simulate this on SW upcasting to fp32 and downcasting to the correct dtype for mod and div.
2. Width A narrower dtype will be cast to the wider dtype. This way fp8 x bf16 will return bf16
3. Prefer float16 If two fp dtypes have the same width, the operation will be performed on fp16. This covers the current semantics of fp8 x fp8 returns fp16 and ``fp16xbf16` returns `fp16`.

For reference, the current implementation lives at

triton/python/triton/language/semantic.py

Lines 82 to 96 in a0c1bc9

	# 3 ) if one operand is half, the other is implicitly converted to half
	# unless we're doing / or %, which do not exist natively in PTX for fp16.
	# Supported PTX op: add, sub, mul, fma, neg, abs, min, max, tanh, ex2, setp
	if a_ty.is_fp16() or b_ty.is_fp16():
	if div_or_mod:
	return tl.float32
	else:
	return tl.float16
	# 4) return bf16 only if both operands are of bf16
	if a_ty.is_bf16() or b_ty.is_bf16():
	if div_or_mod:
	return tl.float32
	if a_ty.is_bf16() and b_ty.is_bf16():
	return tl.bfloat16
	return tl.float32

[iclementine]

Hello，can you also check that does this PR changes this issue #4676 ?

I found that % by 0 have different results when it co-exsits with // by 0 in a kernel.