[PATCH] D15294: [x86] inline calls to fmaxf / llvm.maxnum.f32 using maxss (PR24475)

Sanjay Patel via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 7 10:43:59 PST 2015


spatel created this revision.
spatel added reviewers: scanon, qcolombet, jmolloy.
spatel added a subscriber: llvm-commits.

This patch implements the suggested codegen from PR24475:
https://llvm.org/bugs/show_bug.cgi?id=24475

but only for the fmaxf() case to start, so we can sort out any bugs before extending to fmin, f64, and vectors.

The fmax / maxnum definitions provide us flexibility for signed zeros, so I hope the only thing we have to worry about in this replacement sequence is NaN handling.

Note 1: I initially implemented this as lowerFMAXNUM(), but that exposes a problem: SelectionDAGBuilder::visitSelect() transforms compare/select instructions into FMAXNUM nodes if we declare FMAXNUM legal or custom. Perhaps this should be checking for NaN inputs or global unsafe-math before transforming? As it stands, this bypasses a big set of optimizations that the x86 backend already has in PerformSELECTCombine(). I don't know what the tradeoffs are for making a 'combine' rather than a 'lower'. If a 'lower' is preferred, we will need to fix that problem.

Note 2: The v2f32 test reveals another bug; the vector is extended to v4f32, so we have completely unnecessary operations happening on undef elements of the vector.


http://reviews.llvm.org/D15294

Files:
  lib/Target/X86/X86ISelLowering.cpp
  test/CodeGen/X86/fmaxnum.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D15294.42078.patch
Type: text/x-patch
Size: 16662 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151207/423dec2e/attachment.bin>


More information about the llvm-commits mailing list