1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 11:13:28 +01:00
llvm-mirror/test/CodeGen/X86/mulx64.ll
Craig Topper 7e64cc155b [X86] Restore selection of MULX on BMI2 targets.
Looking back over gcc and icc behavior it looks like icc does
use mulx32 on 32-bit targets and mulx64 on 64-bit targets. It's
also used when dividing i32 by constant on 32-bit targets and
i64 by constant on 64-bit targets.

gcc uses it multiplies producing a 64 bit result on 32-bit targets
and 128-bit results on a 64-bit target. gcc does not appear to use
it for division by constant.

After this patch clang is closer to the icc behavior. This
basically reverts d1c61861ddc94457b08a5a653d3908b7b38ebb22, but
there were no strong feelings at the time.

Fixes PR45518.

Differential Revision: https://reviews.llvm.org/D80498
2020-05-27 12:01:18 -07:00

29 lines
777 B
LLVM

; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+bmi2 | FileCheck %s
; RUN: llc < %s -mtriple=x86_64-unknown -mcpu=core-avx2 | FileCheck %s
define i128 @f1(i64 %a, i64 %b) {
; CHECK-LABEL: f1:
; CHECK: # %bb.0:
; CHECK-NEXT: movq %rdi, %rdx
; CHECK-NEXT: mulxq %rsi, %rax, %rdx
; CHECK-NEXT: retq
%x = zext i64 %a to i128
%y = zext i64 %b to i128
%r = mul i128 %x, %y
ret i128 %r
}
define i128 @f2(i64 %a, i64* %p) {
; CHECK-LABEL: f2:
; CHECK: # %bb.0:
; CHECK-NEXT: movq %rdi, %rdx
; CHECK-NEXT: mulxq (%rsi), %rax, %rdx
; CHECK-NEXT: retq
%b = load i64, i64* %p
%x = zext i64 %a to i128
%y = zext i64 %b to i128
%r = mul i128 %x, %y
ret i128 %r
}