summaryrefslogtreecommitdiffstats
path: root/llvm/test/Bitcode/function-encoding-rel-operands.ll
diff options
context:
space:
mode:
authorDavid Majnemer <david.majnemer@gmail.com>2013-06-29 08:40:07 +0000
committerDavid Majnemer <david.majnemer@gmail.com>2013-06-29 08:40:07 +0000
commit797227eea6113f242d34d4f100611b7d8172888a (patch)
treef6961658e60b8070807dc1d18c2de3fa652baab1 /llvm/test/Bitcode/function-encoding-rel-operands.ll
parent32d1e730237cd925cddaec6af67d85204080301d (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud