[PATCH] D70852: [InstCombine] Guard maxnum/minnum conversions with a TTI query

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

I was worried that our FMF plumbing in DAG was wrong, but I just checked how x86 deals with this, and it seems to be working:

  declare float @llvm.maxnum.f32(float, float) #0
  
  define float @maxnum_fast(float %arg1, float %arg2) {
    %r = call fast float @llvm.maxnum.f32(float %arg1, float %arg2)
    ret float %r
  }
  
  define float @maxnum_strict(float %arg1, float %arg2) {
    %r = call float @llvm.maxnum.f32(float %arg1, float %arg2)
    ret float %r
  }

Debug output for llc shows that we propagated FMF from the calls to the DAG nodes correctly:

  t5: f32 = fmaxnum nnan ninf nsz arcp contract afn reassoc t2, t4

vs.

  t5: f32 = fmaxnum t2, t4

And x86 then converts the generic nodes to target-specific nodes and instruction selection produces the right asm:

  maxss	%xmm1, %xmm0

vs.

  movaps	%xmm0, %xmm2
  cmpunordss	%xmm0, %xmm2
  movaps	%xmm2, %xmm3
  andps	%xmm1, %xmm3
  maxss	%xmm0, %xmm1
  andnps	%xmm1, %xmm2
  orps	%xmm3, %xmm2
  movaps	%xmm2, %xmm0

x86 is choosing not to use a libcall because inline code should be faster, but if you add 'minsize', you'll get a libcall to 'fmaxf'. So all possibilities should be covered, and SystemZ should be able to copy/share that logic.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70852/new/

https://reviews.llvm.org/D70852