RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-01-31 20:51:52 +01:00
Code Issues Projects Releases Wiki Activity
llvm-mirror/test/CodeGen/X86/mulx64.ll

29 lines
777 B
LLVM
Raw Normal View History

[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; 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
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
define i128 @f1(i64 %a, i64 %b) {
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-LABEL: f1:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-04 17:18:51 +00:00
; CHECK: # %bb.0:
[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 11:12:05 -07:00
; CHECK-NEXT: movq %rdi, %rdx
; CHECK-NEXT: mulxq %rsi, %rax, %rdx
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-NEXT: retq
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
%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) {
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-LABEL: f2:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-04 17:18:51 +00:00
; CHECK: # %bb.0:
[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 11:12:05 -07:00
; CHECK-NEXT: movq %rdi, %rdx
; CHECK-NEXT: mulxq (%rsi), %rax, %rdx
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-NEXT: retq
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-27 21:17:42 +00:00
%b = load i64, i64* %p
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
%x = zext i64 %a to i128
%y = zext i64 %b to i128
%r = mul i128 %x, %y
ret i128 %r
}
Reference in New Issue Copy Permalink