diff options
author | David Majnemer <david.majnemer@gmail.com> | 2013-06-29 08:40:07 +0000 |
---|---|---|
committer | David Majnemer <david.majnemer@gmail.com> | 2013-06-29 08:40:07 +0000 |
commit | 797227eea6113f242d34d4f100611b7d8172888a (patch) | |
tree | f6961658e60b8070807dc1d18c2de3fa652baab1 /llvm/test/Bitcode/function-encoding-rel-operands.ll | |
parent | 32d1e730237cd925cddaec6af67d85204080301d (diff) | |
download | bcm5719-llvm-797227eea6113f242d34d4f100611b7d8172888a.tar.gz bcm5719-llvm-797227eea6113f242d34d4f100611b7d8172888a.zip |
InstCombine: Be more agressive optimizing 'udiv' instrs with 'select' denoms
Real world code sometimes has the denominator of a 'udiv' be a
'select'. LLVM can handle such cases but only when the 'select'
operands are symmetric in structure (both select operands are a constant
power of two or a left shift, etc.). This falls apart if we are dealt a
'udiv' where the code is not symetric or if the select operands lead us
to more select instructions.
Instead, we should treat the LHS and each select operand as a distinct
divide operation and try to optimize them independently. If we can
to simplify each operation, then we can replace the 'udiv' with, say, a
'lshr' that has a new select with a bunch of new operands for the
select.
llvm-svn: 185257
Diffstat (limited to 'llvm/test/Bitcode/function-encoding-rel-operands.ll')
0 files changed, 0 insertions, 0 deletions