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/mulx32.ll

30 lines
844 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=i686-unknown -mattr=+bmi2 | FileCheck %s
; RUN: llc < %s -mtriple=i686-unknown -mcpu=core-avx2 | FileCheck %s
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
define i64 @f1(i32 %a, i32 %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: movl {{[0-9]+}}(%esp), %edx
; CHECK-NEXT: mulxl {{[0-9]+}}(%esp), %eax, %edx
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-NEXT: retl
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
%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) {
[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: movl {{[0-9]+}}(%esp), %edx
[DAGCombiner] Set the right SDLoc on a newly-created zextload (1/N) Setting the right SDLoc on a newly-created zextload fixes a line table bug which resulted in non-linear stepping behavior. Several backend tests contained CHECK lines which relied on the IROrder inherited from the wrong SDLoc. This patch breaks that dependence where feasbile and regenerates test cases where not. In some cases, changing a node's IROrder may alter register allocation and spill behavior. This can affect performance. I have chosen not to prevent this by applying a "known good" IROrder to SDLocs, as this may hide a more general bug in the scheduler, or cause regressions on other test inputs. rdar://33755881, Part of: llvm.org/PR37262 Differential Revision: https://reviews.llvm.org/D45995 llvm-svn: 331300
2018-05-01 19:26:15 +00:00
; CHECK-NEXT: movl {{[0-9]+}}(%esp), %eax
[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: mulxl (%eax), %eax, %edx
[X86][BMI2] Regenerate mulx tests llvm-svn: 294598
2017-02-09 17:54:51 +00:00
; CHECK-NEXT: retl
[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 i32, i32* %p
Add MULX code generation support llvm-svn: 164673
2012-09-26 08:22:37 +00:00
%x = zext i32 %a to i64
%y = zext i32 %b to i64
%r = mul i64 %x, %y
ret i64 %r
}
Reference in New Issue Copy Permalink