search for: nonsatur

...was scattered and target-specific and that my best implementation option was to > copy a ton of code from Clang. It might not be a ton, but at some level you'd have to copy a bit of code. There's several fixed-point operations that probably don't deserve their own intrinsics, like nonsaturating fixed-fixed and fixed-int conversion. There's always the possibility of adding them to IRBuilder if we think they might need to be reused. > > The main downsides of not having a type are: > > - Every operation that would've been overloaded by operand type instead has...

...and target-specific and that my best implementation option was to >>> copy a ton of code from Clang. >> It might not be a ton, but at some level you'd have to copy a bit of code. There's several fixed-point operations that probably don't deserve their own intrinsics, like nonsaturating fixed-fixed and fixed-int conversion. > Why not? I mean, sure, they're easy to define with extends and shifts, but it doesn't really seem *bad* to have intrinsics for them. I guess you'd lose some small amount of free integer optimization from the middle-end, but the important...

If we were to create a new type down the line, I think the main features that would distinguish them from other types are the arbitrary width and scale. Saturation can be handled through instructions since saturation really only takes effect after an operation and doesn’t really describe anything about the bits in the resulting type. Signage can similarly be managed through operations and would be