diff options
author | Simon Pilgrim <llvm-dev@redking.me.uk> | 2017-01-04 08:05:42 +0000 |
---|---|---|
committer | Simon Pilgrim <llvm-dev@redking.me.uk> | 2017-01-04 08:05:42 +0000 |
commit | c76ea4b6381f120acaef60a183b2c570d125ef7d (patch) | |
tree | 21380d2ba3b729d36c3cb25ac40360d0020503bd /llvm/lib/Target/XCore/XCoreTargetObjectFile.cpp | |
parent | d0aa53b9ae0b1bd1b093f3d40e0a0e9e128dedd2 (diff) | |
download | bcm5719-llvm-c76ea4b6381f120acaef60a183b2c570d125ef7d.tar.gz bcm5719-llvm-c76ea4b6381f120acaef60a183b2c570d125ef7d.zip |
[X86] Attempt to pre-truncate arithmetic operations if useful
In some cases its more efficient to combine TRUNC( BINOP( X, Y ) ) --> BINOP( TRUNC( X ), TRUNC( Y ) ) if the binop is legal for the truncated types.
This is true for vector integer multiplication (especially vXi64), as well as ADD/AND/XOR/OR in cases where we only need to truncate one of the inputs at runtime (e.g. a duplicated input or an one use constant we can fold).
Further work could be done here - scalar cases (especially i64) could often benefit (if we avoid partial registers etc.), other opcodes, and better analysis of when truncating the inputs reduces costs.
I have considered implementing this for all targets within the DAGCombiner but wasn't sure we could devise a suitable cost model system that would give us the range we need.
Differential Revision: https://reviews.llvm.org/D28219
llvm-svn: 290947
Diffstat (limited to 'llvm/lib/Target/XCore/XCoreTargetObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions