[HLSL] Propose and discuss a holistic approach to math operations in HLSL

[bogner]

From @farzonl's investigation of #83882 it's become clear that splitting up HLSL math operations between generic LLVM intrinsics and special cased HLSL intrinsics is pretty unfortunate. We would prefer to avoid having to implement a large chunk of generic math operations in our own playground, and instead handle them generically in LLVM.

To do this, we should propose implementing the set of math intrinsics we're interested in as generic LLVM intrinsics, and work with the community to get to a solution that makes sense across the board.

A couple of things to note:

1. A chunk of the community has been reticent to accept new math intrinsics in the past (see https://discourse.llvm.org/t/math-intrinsics/67192, [HLSL] Implementation of tan intrinsic  #79948, etc), but there have been discussions debating the split between libcalls and intrinsics for math for a very long time (https://discourse.llvm.org/t/rfc-canonicalize-libcalls-to-intrinsics/39697)
2. The proposal should discuss the full set of math operations we're interested in so that people understand the full picture when discussing this.

AC: This work item tracks sending the initial RFC and driving the conversation to an actionable conclusion.

[bogner]

I took a look through the HLSL Intrinsics, HLSL 6.0 Intrinsics, HLSL 6.4 Intrinsics, and DXIL Ops and filtered down to the simple math operations manually. From there we see a few things.

There are 26 operations that map trivially to existing LLVM intrinsics. Note that three of these don't have direct HLSL intrinsics - IsNormal seems to be unused, and UAddc/USubb are only used by expansions of 64 bit math in dxc. Nothing needs to be done for these.

HLSL Intrinsic	DXIL Op	LLVM Intrinsic
abs (float)	FAbs	llvm.fabs
abs (int)		llvm.abs
ceil	Round_pi	llvm.ceil
cos	Cos	llvm.cos
countbits	Countbits	llvm.ctpop
exp2	Exp	llvm.exp2
floor	Round_ni	llvm.floor
fma	Fma	llvm.fma
frac	Frc	llvm.frexp
isfinite	IsFinite	llvm.is.fpclass
isinf	IsInf	llvm.is.fpclass
isnan	IsNaN	llvm.is.fpclass
	IsNormal	llvm.is.fpclass
log2	Log	llvm.log2
max (float)	FMax	llvm.maxnum
max (int)	IMax	llvm.smax
max (uint)	UMax	llvm.umax
min (float)	FMin	llvm.minnum
min (int)	IMin	llvm.smin
min (uint)	UMin	llvm.umin
reversebits	Bfrev	llvm.bitreverse
round	Round_ne	llvm.roundeven
sin	Sin	llvm.sin
sqrt	Sqrt	llvm.sqrt
trunc	Round_z	llvm.trunc
	UAddc	llvm.uadd.with.overflow
	USubb	llvm.usub.with.overflow

There are 17 HLSL operations that map directly to C/C++ standard math functions, though only 7 of these have DXIL operations. We should definitely push for adding the 7 DXIL ops as llvm intrinsics, and we should probably just get all of these in.

HLSL Intrinsic	DXIL Op	C stdlib	LLVM Intrinsic
acos	Acos	acos
asin	Asin	asin
atan	Atan	atan
cosh	Hcos	cosh
sinh	Hsin	sinh
tanh	Htan	tanh
tan	Tan	tan
atan2		atan2
exp		exp	llvm.exp
fmod		fmod
frexp		frexp
ldexp		ldexp
log		log	llvm.log
log10		log10	llvm.log10
modf		modf
pow		pow	llvm.pow
sign		copysign

We also have 4 common math operations that don't map to the C standard library, but can be awkward to pattern match on if we lower early. We should consider asking for these as well.

HLSL Intrinsic	DXIL Op
dot	Dot2
dot	Dot3
dot	Dot4
rsqrt	Rsqrt
clamp
rcp

Then there are mad and sincos. I personally don't think these are worth having intrinsics for, as separating them into two operations feels like it won't really lose anything. Note that these are MAD not FMA, so they aren't fused at all.

HLSL Intrinsic	DXIL Op
mad (float)	FMad
mad (int)	IMad
mad (uint)	UMad
sincos

We also have a few bitfield instructions. We should probably pursue getting generic intrinsics for these, as a lot of architectures have this kind of instruction. However, I think it falls outside of the "this is just normal math" umbrella and we should do that separately.

DXIL Op
Bfi
Ibfe
Ubfe

Next we have operations that seem like they should map simply to intrinsics, but they're defined to return 0xffffffff instead of poison in edge cases. I don't really know what to do with these, but we clearly can't define them as generic intrinsics.

HLSL Intrinsic	DXIL Op
firstbithigh	FirstbitSHi
firstbithigh	FirstbitHi
firstbitlow	FirstbitLo
	UDiv

After that we're left with some highly specific operations. I can't see implementing any of these generically, though saturate could pretty trivially be implemented in terms of clamp if we add that one.

HLSL Intrinsic	DXIL Op
dot2add	Dot2AddHalf
dot4add_i8packed	Dot4AddI8Packed
dot4add_u8packed	Dot4AddU8Packed
msad4	MSad
saturate	Saturate
	UMul

Finally, there are some utility functions that dxc lowers early. I suspect we should simply do the same and there isn't any value kicking them around as intrinsics.

HLSL Intrinsic
all
any
degrees
radians
step

Conclusions

1. We should propose adding 17 math intrinsics that map to C standard math functions: acos, asin, atan, cosh, sinh, tanh, tan, atan2, exp, fmod, frexp, ldexp, log, log10, modf, pow, and copysign.
2. We should propose adding intrinsics for dot, rsqrt, clamp, and rcp.
3. We should propose adding bitfield extract and insert intrisics.

[farzonl]

First Thanks @bogner for putting this list together. I think it's a good starting point for discussion. There are a few corrections We need to make in the backend That this list has made clear.

There are others that this list isn't correct on.

First we don't need to propose any of the below they already exist:

1. llvm.exp
2. llvm.log
3. llvm.log10
4. llvm.pow

Second, I don't agree with your mad intrinsic conclusions. First because we have an FMad intrinsic via
llvm.fmulladd
We just lack the signed\unsigned variants. Second if we have a DXIL op that is a good indication we need an intrinsic.

Third DIXL isn't the only backend we would want to consider for our proposal. Part of why we want to make this proposal is because the more math intrinsics exist in LLVM the easier it will be to support the SPIRV backend.
SO, with that said any HLSL's intrinsic that has its own SPIRV opcode lowering should also be considered for a generic intrinsic. So all and any need their own intrinsics b\c they Map to SPIRV instructions.
example: https://shader-playground.timjones.io/2c2f5508935b069873558be1cdb3a2b7

%12 = OpConstantComposite %v4float %float_0 %float_0 %float_0 %float_0
%34 = OpFOrdNotEqual %v4bool %32 %12
%35 = OpAny %bool %34

%38 = OpFOrdNotEqual %v4bool %37 %12
 %39 = OpAll %bool %38

degrees and radians map to GLSL extensions
https://shader-playground.timjones.io/adc906317f915e0d2ce2e22c85565b02

%13 = OpExtInst %v4float %1 Degrees %12
%14 = OpExtInst %v4float %1 Radians %12
%15 = OpExtInst %v4float %1 Step %12 %12 # 

In your conclusions you had dot and rcp listed. We don't need an rcp intrinsic that can just be lowered to 1 / x that seems to be consistent in SPIRV, so I'll make a change to move the lowering of that one out of DXILIntrinsicExpansions.cpp.
As for dot. if we do dot we have to also consider how we are going to handle the integer cases. In DXIL it's a daisy chain of mad operations. In SPIRV it is all multiplies upfront then accumulate them at the end. Do we need an intrinsic for the integer cases since the backend behaviors are different? Also dot for DIXL makes a distinction between using umad\imad but SPIRV has no IR differences between signed and unsigned dot.
https://shader-playground.timjones.io/e7b3068d8b1d1e298b2790f666853d19

%12 = OpCompositeExtract %int %11 0
         %13 = OpIMul %int %12 %12
         %14 = OpCompositeExtract %int %11 1
         %15 = OpIMul %int %14 %14
         %16 = OpCompositeExtract %int %11 2
         %17 = OpIMul %int %16 %16
         %18 = OpCompositeExtract %int %11 3
         %19 = OpIMul %int %18 %18
         %20 = OpIAdd %int %13 %15
         %21 = OpIAdd %int %20 %17
         %22 = OpIAdd %int %21 %19
         %23 = OpCompositeConstruct %v4int %22 %22 %22 %22

So my conclusion is you only need 13 of your math intrinsics (-4).
The 5 utility functions you have listed likely need intrinsics (+5)
We probably need an imad\umad intrinsic since we have an LLVM generic one for (fmad). (+2)
We don't need rcp) (-1)

Does dot need special typed versions (+0 to +2)?