David Green via llvm-dev
2019-Oct-10 15:01 UTC
[llvm-dev] [RFC] Use of saturating intrinsics
Hello all, Over in D68651 I would like to make code that attempt to saturate an value (using higher bitwidth integers) use a saturating intrinsic instead. Something like this: https://godbolt.org/z/9knBnP As can be seen, the unsigned cases are already being matched to llvm.uadd.sat intrinsics. I am hoping to extend that to the signed cases. This has numerous benefits including simpler vectorization, cost-modelling and matching in the backend. The current forms of the saturating intrinsics extend into a higher type, which can be awkward to deal with in some cases (i64's are often not legal types, for example). The intrinsic seems to produce as good or better code in almost all the cases I have tried (partly thanks to patches like D68643 and the many other optimisation over the years into the backend to efficiently optimise these saturating intrinsics, even when they are not natively available.) As noted in the review, this does bring up the question of what we should consider canonical. I believe that these intrinsics should be (especially over changing types!). Let us know if you disagree. Cheers Dave IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
David Green via llvm-dev
2019-Oct-10 15:14 UTC
[llvm-dev] [RFC] Use of saturating intrinsics
Urgh. I was promised that wouldn't be happening any more. Let me resend this without the notice on the end. Apologies for the noise. Dave From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of David Green via llvm-dev <llvm-dev at lists.llvm.org> Sent: 10 October 2019 16:01 To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] [RFC] Use of saturating intrinsics Hello all, Over in D68651 I would like to make code that attempt to saturate an value (using higher bitwidth integers) use a saturating intrinsic instead. Something like this: https://godbolt.org/z/9knBnP As can be seen, the unsigned cases are already being matched to llvm.uadd.sat intrinsics. I am hoping to extend that to the signed cases. This has numerous benefits including simpler vectorization, cost-modelling and matching in the backend. The current forms of the saturating intrinsics extend into a higher type, which can be awkward to deal with in some cases (i64's are often not legal types, for example). The intrinsic seems to produce as good or better code in almost all the cases I have tried (partly thanks to patches like D68643 and the many other optimisation over the years into the backend to efficiently optimise these saturating intrinsics, even when they are not natively available.) As noted in the review, this does bring up the question of what we should consider canonical. I believe that these intrinsics should be (especially over changing types!). Let us know if you disagree. Cheers Dave IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev