1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 12:12:47 +01:00
llvm-mirror/test/CodeGen/X86/muloti.ll
Eli Friedman ca89c6b055 [SelectionDAG] Improve the legalisation lowering of UMULO.
There is no way in the universe, that doing a full-width division in
software will be faster than doing overflowing multiplication in
software in the first place, especially given that this same full-width
multiplication needs to be done anyway.

This patch replaces the previous implementation with a direct lowering
into an overflowing multiplication algorithm based on half-width
operations.

Correctness of the algorithm was verified by exhaustively checking the
output of this algorithm for overflowing multiplication of 16 bit
integers against an obviously correct widening multiplication. Baring
any oversights introduced by porting the algorithm to DAG, confidence in
correctness of this algorithm is extremely high.

Following table shows the change in both t = runtime and s = space. The
change is expressed as a multiplier of original, so anything under 1 is
“better” and anything above 1 is worse.

+-------+-----------+-----------+-------------+-------------+
| Arch  | u64*u64 t | u64*u64 s | u128*u128 t | u128*u128 s |
+-------+-----------+-----------+-------------+-------------+
|   X64 |     -     |     -     |    ~0.5     |    ~0.64    |
|  i686 |   ~0.5    |   ~0.6666 |    ~0.05    |    ~0.9     |
| armv7 |     -     |   ~0.75   |      -      |    ~1.4     |
+-------+-----------+-----------+-------------+-------------+

Performance numbers have been collected by running overflowing
multiplication in a loop under `perf` on two x86_64 (one Intel Haswell,
other AMD Ryzen) based machines. Size numbers have been collected by
looking at the size of function containing an overflowing multiply in
a loop.

All in all, it can be seen that both performance and size has improved
except in the case of armv7 where code size has regressed for 128-bit
multiply. u128*u128 overflowing multiply on 32-bit platforms seem to
benefit from this change a lot, taking only 5% of the time compared to
original algorithm to calculate the same thing.

The final benefit of this change is that LLVM is now capable of lowering
the overflowing unsigned multiply for integers of any bit-width as long
as the target is capable of lowering regular multiplication for the same
bit-width. Previously, 128-bit overflowing multiply was the widest
possible.

Patch by Simonas Kazlauskas!

Differential Revision: https://reviews.llvm.org/D50310

llvm-svn: 339922
2018-08-16 18:39:39 +00:00

38 lines
1.2 KiB
LLVM

; RUN: llc < %s -mtriple=x86_64-apple-darwin | FileCheck %s
%0 = type { i64, i64 }
%1 = type { i128, i1 }
define %0 @x(i64 %a.coerce0, i64 %a.coerce1, i64 %b.coerce0, i64 %b.coerce1) nounwind uwtable ssp {
; CHECK: x
entry:
%tmp16 = zext i64 %a.coerce0 to i128
%tmp11 = zext i64 %a.coerce1 to i128
%tmp12 = shl nuw i128 %tmp11, 64
%ins14 = or i128 %tmp12, %tmp16
%tmp6 = zext i64 %b.coerce0 to i128
%tmp3 = zext i64 %b.coerce1 to i128
%tmp4 = shl nuw i128 %tmp3, 64
%ins = or i128 %tmp4, %tmp6
%0 = tail call %1 @llvm.smul.with.overflow.i128(i128 %ins14, i128 %ins)
; CHECK: callq ___muloti4
%1 = extractvalue %1 %0, 0
%2 = extractvalue %1 %0, 1
br i1 %2, label %overflow, label %nooverflow
overflow: ; preds = %entry
tail call void @llvm.trap()
unreachable
nooverflow: ; preds = %entry
%tmp20 = trunc i128 %1 to i64
%tmp21 = insertvalue %0 undef, i64 %tmp20, 0
%tmp22 = lshr i128 %1, 64
%tmp23 = trunc i128 %tmp22 to i64
%tmp24 = insertvalue %0 %tmp21, i64 %tmp23, 1
ret %0 %tmp24
}
declare %1 @llvm.smul.with.overflow.i128(i128, i128) nounwind readnone
declare void @llvm.trap() nounwind