mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2025-01-31 20:51:52 +01:00
7e64cc155b
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
30 lines
844 B
LLVM
30 lines
844 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=i686-unknown -mattr=+bmi2 | FileCheck %s
|
|
; RUN: llc < %s -mtriple=i686-unknown -mcpu=core-avx2 | FileCheck %s
|
|
|
|
define i64 @f1(i32 %a, i32 %b) {
|
|
; CHECK-LABEL: f1:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %edx
|
|
; CHECK-NEXT: mulxl {{[0-9]+}}(%esp), %eax, %edx
|
|
; CHECK-NEXT: retl
|
|
%x = zext i32 %a to i64
|
|
%y = zext i32 %b to i64
|
|
%r = mul i64 %x, %y
|
|
ret i64 %r
|
|
}
|
|
|
|
define i64 @f2(i32 %a, i32* %p) {
|
|
; CHECK-LABEL: f2:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %edx
|
|
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
; CHECK-NEXT: mulxl (%eax), %eax, %edx
|
|
; CHECK-NEXT: retl
|
|
%b = load i32, i32* %p
|
|
%x = zext i32 %a to i64
|
|
%y = zext i32 %b to i64
|
|
%r = mul i64 %x, %y
|
|
ret i64 %r
|
|
}
|