diff options
author | Sanjay Patel <spatel@rotateright.com> | 2015-12-15 23:11:43 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2015-12-15 23:11:43 +0000 |
commit | 271efcdf209fe42e3893f62d3bb87975645fbe25 (patch) | |
tree | 266d9578bf644ff0cac56ae29829ac0ff9f74bc4 /lldb/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py | |
parent | 99fcb721b2cf21d16f8b195af05510e6b52d4102 (diff) | |
download | bcm5719-llvm-271efcdf209fe42e3893f62d3bb87975645fbe25.tar.gz bcm5719-llvm-271efcdf209fe42e3893f62d3bb87975645fbe25.zip |
[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
llvm-svn: 255700
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py')
0 files changed, 0 insertions, 0 deletions