Incorrect specialization for modulo operator

[expipiplus1]

In this example, the % operator is being specialized as frem when it's actually operating on int, it should be translated to srem

//TEST(compute):COMPARE_COMPUTE(filecheck-buffer=CHECK):-vk -output-using-type

// CHECK: type: int32_t
// CHECK-NEXT: 0
// CHECK-NEXT: 0
// CHECK-NEXT: 0
// CHECK-NEXT: 0

//TEST_INPUT:ubuffer(data=[0 0 0 0], stride=4):out,name=outputBuffer
RWStructuredBuffer<int> outputBuffer;

T myMod<T : __BuiltinArithmeticType>(T x, T y)
{
    return x % y;
}

[numthreads(4, 1, 1)]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    int c = 1;
    int d = 1;
    outputBuffer[dispatchThreadID.x] = myMod(c,d);
}

[readNone]
[nameHint("myMod")]
func %myMod     : Func(Int, Int, Int)
{
block %19(
                [nameHint("x")]
                param %x        : Int,
                [nameHint("y")]
                param %y        : Int):
        let  %20        : Int   = frem(%x, %y)
        return_val(%20)
}

[jkwak-work]

Isn't frem correct?
What is the expected behavior for this?

In HLSL, operator% is same as fmod, which returns a remainder not modulo.
Doesn't Slang follow the same rule of operator% in HLSL?

[jkwak-work]

I think this issue contradicts to one of already resolved issue.
#1059

[expipiplus1]

Isn't frem correct?...

This doesn't have anything to do with the semantics of the operator, it's that we're failing to translate it correctly at all for integer types when used in a generic context, we should be lowering to SRem in this case, but we are lowering to FRem. Compare to just using the % operator not in a generic function where we correctly lower to SRem or UMod for signed and unsigned ints