Alex Bradbury via llvm-dev
2018-Nov-01 16:45 UTC
[llvm-dev] Proposed new min and max intrinsics
On Thu, 11 Oct 2018 at 00:28, Thomas Lively via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I just wanted to bump this to see if anyone has any input. I would really like to get these landed soon if there are no objections.Hi Thomas, With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target due to these newly exposed intrinsics, I think these nodes should be handled in at least SelectionDAGLegalize::ExpandNode (for when the float type is legal but the operation is not) and DAGTypeLegalizer::SoftenFloatResult (for when the float type is not legal). Best, Alex
Thomas Lively via llvm-dev
2018-Nov-01 18:49 UTC
[llvm-dev] Proposed new min and max intrinsics
Sounds good, I'll take a look. On Thu, Nov 1, 2018 at 9:45 AM Alex Bradbury <asb at asbradbury.org> wrote:> On Thu, 11 Oct 2018 at 00:28, Thomas Lively via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I just wanted to bump this to see if anyone has any input. I would > really like to get these landed soon if there are no objections. > > Hi Thomas, > > With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target > due to these newly exposed intrinsics, I think these nodes should be > handled in at least SelectionDAGLegalize::ExpandNode (for when the > float type is legal but the operation is not) and > DAGTypeLegalizer::SoftenFloatResult (for when the float type is not > legal). > > Best, > > Alex >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181101/95b48ce2/attachment.html>
Thomas Lively via llvm-dev
2018-Nov-08 04:12 UTC
[llvm-dev] Proposed new min and max intrinsics
Alex, After looking into this a bit, it looks to me like the best thing to do for targets that do not natively support ISD::MINIMUM and ISD::MAXIMUM would be to fall back to a libcall, since implementing these operations in terms of existing operations is actually rather complicated. Do you think it would make sense to add builtin functions to compiler-rt to implement these operations, or is there a better way of handling this? Thanks, Thomas On Thu, Nov 1, 2018 at 11:49 AM Thomas Lively <tlively at google.com> wrote:> Sounds good, I'll take a look. > > On Thu, Nov 1, 2018 at 9:45 AM Alex Bradbury <asb at asbradbury.org> wrote: > >> On Thu, 11 Oct 2018 at 00:28, Thomas Lively via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > I just wanted to bump this to see if anyone has any input. I would >> really like to get these landed soon if there are no objections. >> >> Hi Thomas, >> >> With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target >> due to these newly exposed intrinsics, I think these nodes should be >> handled in at least SelectionDAGLegalize::ExpandNode (for when the >> float type is legal but the operation is not) and >> DAGTypeLegalizer::SoftenFloatResult (for when the float type is not >> legal). >> >> Best, >> >> Alex >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181107/a3bc8898/attachment.html>