[x86] inline calls to fmaxf / llvm.maxnum.f32 using maxss (PR24475)
authorSanjay Patel <spatel@rotateright.com>
Tue, 15 Dec 2015 23:11:43 +0000 (23:11 +0000)
committerSanjay Patel <spatel@rotateright.com>
Tue, 15 Dec 2015 23:11:43 +0000 (23:11 +0000)
commit1665eaa17d3ce279a2ee8cf0841a496e6acbe92e
treeee3f74bd90abe98d170a019769c4f3e1d9c16a40
parent3f5723cb6c6a9385541d466fb57cd7358fb6aa88
[x86] inline calls to fmaxf / llvm.maxnum.f32 using maxss (PR24475)

This patch improves on 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 the
only thing we have to worry about in this replacement sequence is NaN handling.

Note 1: It may be better to implement 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
that should be checking for NaN inputs or global unsafe-math before transforming?
As it stands, that bypasses a big set of optimizations that the x86 backend
already has in PerformSELECTCombine().

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.

Differential Revision: http://reviews.llvm.org/D15294

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255700 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86ISelLowering.cpp
test/CodeGen/X86/fmaxnum.ll