2011-02-22 08:19:28 +01:00
|
|
|
; RUN: llc < %s -mtriple=x86_64-linux | FileCheck %s
|
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-win64 | FileCheck %s
|
[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.
Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.
This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.
Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.
** Context **
Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.
** Motivating Example **
Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
%ld = load i8* %addr1
%zextld = zext i8 %ld to i32
%ld2 = load i32* %addr2
%add = add nsw i32 %ld2, %zextld
%sextadd = sext i32 %add to i64
%zexta = zext i8 %a to i32
%addza = add nsw i32 %zexta, %zextld
%sextaddza = sext i32 %addza to i64
%addb = add nsw i32 %b, %zextld
%sextaddb = sext i32 %addb to i64
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
ret void
}
As it is, this IR generates the following assembly on x86_64:
[...]
movzbl (%rdi), %eax # zero-extended load
movl (%rsi), %es # plain load
addl %eax, %esi # 32-bit add
movslq %esi, %rdi # sign extend the result of add
movzbl %dl, %edx # zero extend the first argument
addl %eax, %edx # 32-bit add
movslq %edx, %rsi # sign extend the result of add
addl %eax, %ecx # 32-bit add
movslq %ecx, %rdx # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.
Now, by promoting the additions to form more extended loads we would generate:
[...]
movzbl (%rdi), %eax # zero-extended load
movslq (%rsi), %rdi # sign-extended load
addq %rax, %rdi # 64-bit add
movzbl %dl, %esi # zero extend the first argument
addq %rax, %rsi # 64-bit add
movslq %ecx, %rdx # sign extend the second argument
addq %rax, %rdx # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.
This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.
Note: The throughput numbers are similar on Sandy Bridge and Haswell.
** Proposed Solution **
To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))
The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.
** Performance **
Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar: ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%
The results are consistent for both O3 and Os.
<rdar://problem/18310086>
llvm-svn: 224402
2014-12-17 02:36:17 +01:00
|
|
|
; RUN: opt -codegenprepare < %s -mtriple=x86_64-apple-macosx -S | FileCheck %s --check-prefix=OPTALL --check-prefix=OPT --check-prefix=NONSTRESS
|
|
|
|
|
; RUN: opt -codegenprepare < %s -mtriple=x86_64-apple-macosx -S -stress-cgp-ext-ld-promotion | FileCheck %s --check-prefix=OPTALL --check-prefix=OPT --check-prefix=STRESS
|
|
|
|
|
; RUN: opt -codegenprepare < %s -mtriple=x86_64-apple-macosx -S -disable-cgp-ext-ld-promotion | FileCheck %s --check-prefix=OPTALL --check-prefix=DISABLE
|
2014-12-17 01:29:23 +01:00
|
|
|
|
[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.
Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.
This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.
Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.
** Context **
Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.
** Motivating Example **
Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
%ld = load i8* %addr1
%zextld = zext i8 %ld to i32
%ld2 = load i32* %addr2
%add = add nsw i32 %ld2, %zextld
%sextadd = sext i32 %add to i64
%zexta = zext i8 %a to i32
%addza = add nsw i32 %zexta, %zextld
%sextaddza = sext i32 %addza to i64
%addb = add nsw i32 %b, %zextld
%sextaddb = sext i32 %addb to i64
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
ret void
}
As it is, this IR generates the following assembly on x86_64:
[...]
movzbl (%rdi), %eax # zero-extended load
movl (%rsi), %es # plain load
addl %eax, %esi # 32-bit add
movslq %esi, %rdi # sign extend the result of add
movzbl %dl, %edx # zero extend the first argument
addl %eax, %edx # 32-bit add
movslq %edx, %rsi # sign extend the result of add
addl %eax, %ecx # 32-bit add
movslq %ecx, %rdx # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.
Now, by promoting the additions to form more extended loads we would generate:
[...]
movzbl (%rdi), %eax # zero-extended load
movslq (%rsi), %rdi # sign-extended load
addq %rax, %rdi # 64-bit add
movzbl %dl, %esi # zero extend the first argument
addq %rax, %rsi # 64-bit add
movslq %ecx, %rdx # sign extend the second argument
addq %rax, %rdx # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.
This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.
Note: The throughput numbers are similar on Sandy Bridge and Haswell.
** Proposed Solution **
To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))
The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.
** Performance **
Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar: ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%
The results are consistent for both O3 and Os.
<rdar://problem/18310086>
llvm-svn: 224402
2014-12-17 02:36:17 +01:00
|
|
|
; rdar://7304838
|
2009-10-16 22:59:35 +02:00
|
|
|
; CodeGenPrepare should move the zext into the block with the load
|
|
|
|
|
; so that SelectionDAG can select it with the load.
|
[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.
Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.
This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.
Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.
** Context **
Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.
** Motivating Example **
Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
%ld = load i8* %addr1
%zextld = zext i8 %ld to i32
%ld2 = load i32* %addr2
%add = add nsw i32 %ld2, %zextld
%sextadd = sext i32 %add to i64
%zexta = zext i8 %a to i32
%addza = add nsw i32 %zexta, %zextld
%sextaddza = sext i32 %addza to i64
%addb = add nsw i32 %b, %zextld
%sextaddb = sext i32 %addb to i64
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
ret void
}
As it is, this IR generates the following assembly on x86_64:
[...]
movzbl (%rdi), %eax # zero-extended load
movl (%rsi), %es # plain load
addl %eax, %esi # 32-bit add
movslq %esi, %rdi # sign extend the result of add
movzbl %dl, %edx # zero extend the first argument
addl %eax, %edx # 32-bit add
movslq %edx, %rsi # sign extend the result of add
addl %eax, %ecx # 32-bit add
movslq %ecx, %rdx # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.
Now, by promoting the additions to form more extended loads we would generate:
[...]
movzbl (%rdi), %eax # zero-extended load
movslq (%rsi), %rdi # sign-extended load
addq %rax, %rdi # 64-bit add
movzbl %dl, %esi # zero extend the first argument
addq %rax, %rsi # 64-bit add
movslq %ecx, %rdx # sign extend the second argument
addq %rax, %rdx # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.
This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.
Note: The throughput numbers are similar on Sandy Bridge and Haswell.
** Proposed Solution **
To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))
The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.
** Performance **
Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar: ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%
The results are consistent for both O3 and Os.
<rdar://problem/18310086>
llvm-svn: 224402
2014-12-17 02:36:17 +01:00
|
|
|
;
|
|
|
|
|
; CHECK-LABEL: foo:
|
2013-11-22 20:57:47 +01:00
|
|
|
; CHECK: movsbl ({{%rdi|%rcx}}), %eax
|
[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.
Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.
This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.
Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.
** Context **
Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.
** Motivating Example **
Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
%ld = load i8* %addr1
%zextld = zext i8 %ld to i32
%ld2 = load i32* %addr2
%add = add nsw i32 %ld2, %zextld
%sextadd = sext i32 %add to i64
%zexta = zext i8 %a to i32
%addza = add nsw i32 %zexta, %zextld
%sextaddza = sext i32 %addza to i64
%addb = add nsw i32 %b, %zextld
%sextaddb = sext i32 %addb to i64
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
ret void
}
As it is, this IR generates the following assembly on x86_64:
[...]
movzbl (%rdi), %eax # zero-extended load
movl (%rsi), %es # plain load
addl %eax, %esi # 32-bit add
movslq %esi, %rdi # sign extend the result of add
movzbl %dl, %edx # zero extend the first argument
addl %eax, %edx # 32-bit add
movslq %edx, %rsi # sign extend the result of add
addl %eax, %ecx # 32-bit add
movslq %ecx, %rdx # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.
Now, by promoting the additions to form more extended loads we would generate:
[...]
movzbl (%rdi), %eax # zero-extended load
movslq (%rsi), %rdi # sign-extended load
addq %rax, %rdi # 64-bit add
movzbl %dl, %esi # zero extend the first argument
addq %rax, %rsi # 64-bit add
movslq %ecx, %rdx # sign extend the second argument
addq %rax, %rdx # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.
This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.
Note: The throughput numbers are similar on Sandy Bridge and Haswell.
** Proposed Solution **
To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))
The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.
** Performance **
Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar: ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%
The results are consistent for both O3 and Os.
<rdar://problem/18310086>
llvm-svn: 224402
2014-12-17 02:36:17 +01:00
|
|
|
;
|
|
|
|
|
; OPTALL-LABEL: @foo
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
; OPTALL-NEXT: [[ZEXT:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; OPTALL: store i32 [[ZEXT]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
2009-10-16 22:59:35 +02:00
|
|
|
define void @foo(i8* %p, i32* %q) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = zext i8 %t to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.
Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.
This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.
Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.
** Context **
Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.
** Motivating Example **
Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
%ld = load i8* %addr1
%zextld = zext i8 %ld to i32
%ld2 = load i32* %addr2
%add = add nsw i32 %ld2, %zextld
%sextadd = sext i32 %add to i64
%zexta = zext i8 %a to i32
%addza = add nsw i32 %zexta, %zextld
%sextaddza = sext i32 %addza to i64
%addb = add nsw i32 %b, %zextld
%sextaddb = sext i32 %addb to i64
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
ret void
}
As it is, this IR generates the following assembly on x86_64:
[...]
movzbl (%rdi), %eax # zero-extended load
movl (%rsi), %es # plain load
addl %eax, %esi # 32-bit add
movslq %esi, %rdi # sign extend the result of add
movzbl %dl, %edx # zero extend the first argument
addl %eax, %edx # 32-bit add
movslq %edx, %rsi # sign extend the result of add
addl %eax, %ecx # 32-bit add
movslq %ecx, %rdx # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.
Now, by promoting the additions to form more extended loads we would generate:
[...]
movzbl (%rdi), %eax # zero-extended load
movslq (%rsi), %rdi # sign-extended load
addq %rax, %rdi # 64-bit add
movzbl %dl, %esi # zero extend the first argument
addq %rax, %rsi # 64-bit add
movslq %ecx, %rdx # sign extend the second argument
addq %rax, %rdx # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.
This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.
Note: The throughput numbers are similar on Sandy Bridge and Haswell.
** Proposed Solution **
To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))
The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.
** Performance **
Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar: ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%
The results are consistent for both O3 and Os.
<rdar://problem/18310086>
llvm-svn: 224402
2014-12-17 02:36:17 +01:00
|
|
|
|
|
|
|
|
; Check that we manage to form a zextload is an operation with only one
|
|
|
|
|
; argument to explicitly extend is in the the way.
|
|
|
|
|
; OPTALL-LABEL: @promoteOneArg
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
; OPT-NEXT: [[ZEXT:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; OPT-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nuw i32 [[ZEXT]], 2
|
|
|
|
|
; Make sure the operation is not promoted when the promotion pass is disabled.
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i8 [[LD]], 2
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = zext i8 [[ADD]] to i32
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteOneArg(i8* %p, i32* %q) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%add = add nuw i8 %t, 2
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = zext i8 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to form a sextload is an operation with only one
|
|
|
|
|
; argument to explicitly extend is in the the way.
|
|
|
|
|
; Version with sext.
|
|
|
|
|
; OPTALL-LABEL: @promoteOneArgSExt
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
; OPT-NEXT: [[SEXT:%[a-zA-Z_0-9-]+]] = sext i8 [[LD]] to i32
|
|
|
|
|
; OPT-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nsw i32 [[SEXT]], 2
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i8 [[LD]], 2
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = sext i8 [[ADD]] to i32
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteOneArgSExt(i8* %p, i32* %q) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%add = add nsw i8 %t, 2
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = sext i8 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to form a zextload is an operation with two
|
|
|
|
|
; arguments to explicitly extend is in the the way.
|
|
|
|
|
; Extending %add will create two extensions:
|
|
|
|
|
; 1. One for %b.
|
|
|
|
|
; 2. One for %t.
|
|
|
|
|
; #1 will not be removed as we do not know anything about %b.
|
|
|
|
|
; #2 may not be merged with the load because %t is used in a comparison.
|
|
|
|
|
; Since two extensions may be emitted in the end instead of one before the
|
|
|
|
|
; transformation, the regular heuristic does not apply the optimization.
|
|
|
|
|
;
|
|
|
|
|
; OPTALL-LABEL: @promoteTwoArgZext
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
;
|
|
|
|
|
; STRESS-NEXT: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; STRESS-NEXT: [[ZEXTB:%[a-zA-Z_0-9-]+]] = zext i8 %b to i32
|
|
|
|
|
; STRESS-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nuw i32 [[ZEXTLD]], [[ZEXTB]]
|
|
|
|
|
;
|
|
|
|
|
; NONSTRESS: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i8 [[LD]], %b
|
|
|
|
|
; NONSTRESS: [[RES:%[a-zA-Z_0-9-]+]] = zext i8 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i8 [[LD]], %b
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = zext i8 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteTwoArgZext(i8* %p, i32* %q, i8 %b) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%add = add nuw i8 %t, %b
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = zext i8 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to form a sextload is an operation with two
|
|
|
|
|
; arguments to explicitly extend is in the the way.
|
|
|
|
|
; Version with sext.
|
|
|
|
|
; OPTALL-LABEL: @promoteTwoArgSExt
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
;
|
|
|
|
|
; STRESS-NEXT: [[SEXTLD:%[a-zA-Z_0-9-]+]] = sext i8 [[LD]] to i32
|
|
|
|
|
; STRESS-NEXT: [[SEXTB:%[a-zA-Z_0-9-]+]] = sext i8 %b to i32
|
|
|
|
|
; STRESS-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nsw i32 [[SEXTLD]], [[SEXTB]]
|
|
|
|
|
;
|
|
|
|
|
; NONSTRESS: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i8 [[LD]], %b
|
|
|
|
|
; NONSTRESS: [[RES:%[a-zA-Z_0-9-]+]] = sext i8 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i8 [[LD]], %b
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = sext i8 [[ADD]] to i32
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteTwoArgSExt(i8* %p, i32* %q, i8 %b) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%add = add nsw i8 %t, %b
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = sext i8 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we do not a zextload if we need to introduce more than
|
|
|
|
|
; one additional extension.
|
|
|
|
|
; OPTALL-LABEL: @promoteThreeArgZext
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
;
|
|
|
|
|
; STRESS-NEXT: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; STRESS-NEXT: [[ZEXTB:%[a-zA-Z_0-9-]+]] = zext i8 %b to i32
|
|
|
|
|
; STRESS-NEXT: [[TMP:%[a-zA-Z_0-9-]+]] = add nuw i32 [[ZEXTLD]], [[ZEXTB]]
|
|
|
|
|
; STRESS-NEXT: [[ZEXTC:%[a-zA-Z_0-9-]+]] = zext i8 %c to i32
|
|
|
|
|
; STRESS-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nuw i32 [[TMP]], [[ZEXTC]]
|
|
|
|
|
;
|
|
|
|
|
; NONSTRESS-NEXT: [[TMP:%[a-zA-Z_0-9-]+]] = add nuw i8 [[LD]], %b
|
|
|
|
|
; NONSTRESS-NEXT: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i8 [[TMP]], %c
|
|
|
|
|
; NONSTRESS: [[RES:%[a-zA-Z_0-9-]+]] = zext i8 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: add nuw i8
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i8
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = zext i8 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteThreeArgZext(i8* %p, i32* %q, i8 %b, i8 %c) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%tmp = add nuw i8 %t, %b
|
|
|
|
|
%add = add nuw i8 %tmp, %c
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = zext i8 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to form a zextload after promoting and merging
|
|
|
|
|
; two extensions.
|
|
|
|
|
; OPTALL-LABEL: @promoteMergeExtArgZExt
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
;
|
|
|
|
|
; STRESS-NEXT: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; STRESS-NEXT: [[ZEXTB:%[a-zA-Z_0-9-]+]] = zext i16 %b to i32
|
|
|
|
|
; STRESS-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nuw i32 [[ZEXTLD]], [[ZEXTB]]
|
|
|
|
|
;
|
|
|
|
|
; NONSTRESS: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i16
|
|
|
|
|
; NONSTRESS: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i16 [[ZEXTLD]], %b
|
|
|
|
|
; NONSTRESS: [[RES:%[a-zA-Z_0-9-]+]] = zext i16 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i16
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw i16 [[ZEXTLD]], %b
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = zext i16 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteMergeExtArgZExt(i8* %p, i32* %q, i16 %b) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%ext = zext i8 %t to i16
|
|
|
|
|
%add = add nuw i16 %ext, %b
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = zext i16 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to form a sextload after promoting and merging
|
|
|
|
|
; two extensions.
|
|
|
|
|
; Version with sext.
|
|
|
|
|
; OPTALL-LABEL: @promoteMergeExtArgSExt
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %p
|
|
|
|
|
;
|
|
|
|
|
; STRESS-NEXT: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i32
|
|
|
|
|
; STRESS-NEXT: [[ZEXTB:%[a-zA-Z_0-9-]+]] = sext i16 %b to i32
|
|
|
|
|
; STRESS-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nsw i32 [[ZEXTLD]], [[ZEXTB]]
|
|
|
|
|
;
|
|
|
|
|
; NONSTRESS: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i16
|
|
|
|
|
; NONSTRESS: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i16 [[ZEXTLD]], %b
|
|
|
|
|
; NONSTRESS: [[RES:%[a-zA-Z_0-9-]+]] = sext i16 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: [[ZEXTLD:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i16
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i16 [[ZEXTLD]], %b
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = sext i16 [[ADD]] to i32
|
|
|
|
|
; OPTALL: store i32 [[RES]], i32* %q
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @promoteMergeExtArgSExt(i8* %p, i32* %q, i16 %b) {
|
|
|
|
|
entry:
|
|
|
|
|
%t = load i8* %p
|
|
|
|
|
%ext = zext i8 %t to i16
|
|
|
|
|
%add = add nsw i16 %ext, %b
|
|
|
|
|
%a = icmp slt i8 %t, 20
|
|
|
|
|
br i1 %a, label %true, label %false
|
|
|
|
|
true:
|
|
|
|
|
%s = sext i16 %add to i32
|
|
|
|
|
store i32 %s, i32* %q
|
|
|
|
|
ret void
|
|
|
|
|
false:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Check that we manage to catch all the extload opportunities that are exposed
|
|
|
|
|
; by the different iterations of codegen prepare.
|
|
|
|
|
; Moreover, check that we do not promote more than we need to.
|
|
|
|
|
; Here is what is happening in this test (not necessarly in this order):
|
|
|
|
|
; 1. We try to promote the operand of %sextadd.
|
|
|
|
|
; a. This creates one sext of %ld2 and one of %zextld
|
|
|
|
|
; b. The sext of %ld2 can be combine with %ld2, so we remove one sext but
|
|
|
|
|
; introduced one. This is fine with the current heuristic: neutral.
|
|
|
|
|
; => We have one zext of %zextld left and we created one sext of %ld2.
|
|
|
|
|
; 2. We try to promote the operand of %sextaddza.
|
|
|
|
|
; a. This creates one sext of %zexta and one of %zextld
|
|
|
|
|
; b. The sext of %zexta does not lead to any load, it stays here, even if it
|
|
|
|
|
; could have been combine with the zext of %a.
|
|
|
|
|
; c. The sext of %zextld leads to %ld and can be combined with it. This is
|
|
|
|
|
; done by promoting %zextld. This is fine with the current heuristic:
|
|
|
|
|
; neutral.
|
|
|
|
|
; => We have created a new zext of %ld and we created one sext of %zexta.
|
|
|
|
|
; 3. We try to promote the operand of %sextaddb.
|
|
|
|
|
; a. This creates one sext of %b and one of %zextld
|
|
|
|
|
; b. The sext of %b is a dead-end, nothing to be done.
|
|
|
|
|
; c. Same thing as 2.c. happens.
|
|
|
|
|
; => We have created a new zext of %ld and we created one sext of %b.
|
|
|
|
|
; 4. We try to promote the operand of the zext of %zextld introduced in #1.
|
|
|
|
|
; a. Same thing as 2.c. happens.
|
|
|
|
|
; b. %zextld does not have any other uses. It is dead coded.
|
|
|
|
|
; => We have created a new zext of %ld and we removed a zext of %zextld and
|
|
|
|
|
; a zext of %ld.
|
|
|
|
|
; Currently we do not try to reuse existing extensions, so in the end we have
|
|
|
|
|
; 3 identical zext of %ld. The extensions will be CSE'ed by SDag.
|
|
|
|
|
;
|
|
|
|
|
; OPTALL-LABEL: @severalPromotions
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i8* %addr1
|
|
|
|
|
; OPT-NEXT: [[ZEXTLD1_1:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i64
|
|
|
|
|
; OPT-NEXT: [[ZEXTLD1_2:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i64
|
|
|
|
|
; OPT-NEXT: [[ZEXTLD1_3:%[a-zA-Z_0-9-]+]] = zext i8 [[LD]] to i64
|
|
|
|
|
; OPT-NEXT: [[LD2:%[a-zA-Z_0-9-]+]] = load i32* %addr2
|
|
|
|
|
; OPT-NEXT: [[SEXTLD2:%[a-zA-Z_0-9-]+]] = sext i32 [[LD2]] to i64
|
|
|
|
|
; OPT-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nsw i64 [[SEXTLD2]], [[ZEXTLD1_1]]
|
|
|
|
|
; We do not combine this one: see 2.b.
|
|
|
|
|
; OPT-NEXT: [[ZEXTA:%[a-zA-Z_0-9-]+]] = zext i8 %a to i32
|
|
|
|
|
; OPT-NEXT: [[SEXTZEXTA:%[a-zA-Z_0-9-]+]] = sext i32 [[ZEXTA]] to i64
|
|
|
|
|
; OPT-NEXT: [[RESZA:%[a-zA-Z_0-9-]+]] = add nsw i64 [[SEXTZEXTA]], [[ZEXTLD1_3]]
|
|
|
|
|
; OPT-NEXT: [[SEXTB:%[a-zA-Z_0-9-]+]] = sext i32 %b to i64
|
|
|
|
|
; OPT-NEXT: [[RESB:%[a-zA-Z_0-9-]+]] = add nsw i64 [[SEXTB]], [[ZEXTLD1_2]]
|
|
|
|
|
;
|
|
|
|
|
; DISABLE: [[ADD:%[a-zA-Z_0-9-]+]] = add nsw i32
|
|
|
|
|
; DISABLE: [[RES:%[a-zA-Z_0-9-]+]] = sext i32 [[ADD]] to i64
|
|
|
|
|
; DISABLE: [[ADDZA:%[a-zA-Z_0-9-]+]] = add nsw i32
|
|
|
|
|
; DISABLE: [[RESZA:%[a-zA-Z_0-9-]+]] = sext i32 [[ADDZA]] to i64
|
|
|
|
|
; DISABLE: [[ADDB:%[a-zA-Z_0-9-]+]] = add nsw i32
|
|
|
|
|
; DISABLE: [[RESB:%[a-zA-Z_0-9-]+]] = sext i32 [[ADDB]] to i64
|
|
|
|
|
;
|
|
|
|
|
; OPTALL: call void @dummy(i64 [[RES]], i64 [[RESZA]], i64 [[RESB]])
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @severalPromotions(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
|
|
|
|
|
%ld = load i8* %addr1
|
|
|
|
|
%zextld = zext i8 %ld to i32
|
|
|
|
|
%ld2 = load i32* %addr2
|
|
|
|
|
%add = add nsw i32 %ld2, %zextld
|
|
|
|
|
%sextadd = sext i32 %add to i64
|
|
|
|
|
%zexta = zext i8 %a to i32
|
|
|
|
|
%addza = add nsw i32 %zexta, %zextld
|
|
|
|
|
%sextaddza = sext i32 %addza to i64
|
|
|
|
|
%addb = add nsw i32 %b, %zextld
|
|
|
|
|
%sextaddb = sext i32 %addb to i64
|
|
|
|
|
call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
declare void @dummy(i64, i64, i64)
|
|
|
|
|
|
|
|
|
|
; Make sure we do not try to promote vector types since the type promotion
|
|
|
|
|
; helper does not support them for now.
|
|
|
|
|
; OPTALL-LABEL: @vectorPromotion
|
|
|
|
|
; OPTALL: [[SHL:%[a-zA-Z_0-9-]+]] = shl nuw nsw <2 x i32> zeroinitializer, <i32 8, i32 8>
|
|
|
|
|
; OPTALL: [[ZEXT:%[a-zA-Z_0-9-]+]] = zext <2 x i32> [[SHL]] to <2 x i64>
|
|
|
|
|
; OPTALL: ret
|
|
|
|
|
define void @vectorPromotion() {
|
|
|
|
|
entry:
|
|
|
|
|
%a = shl nuw nsw <2 x i32> zeroinitializer, <i32 8, i32 8>
|
|
|
|
|
%b = zext <2 x i32> %a to <2 x i64>
|
|
|
|
|
ret void
|
|
|
|
|
}
|
2014-12-22 19:11:52 +01:00
|
|
|
|
|
|
|
|
@a = common global i32 0, align 4
|
|
|
|
|
@c = common global [2 x i32] zeroinitializer, align 4
|
|
|
|
|
|
|
|
|
|
; PR21978.
|
|
|
|
|
; Make sure we support promotion of operands that produces a Value as opposed
|
|
|
|
|
; to an instruction.
|
|
|
|
|
; This used to cause a crash.
|
|
|
|
|
; OPTALL-LABEL: @promotionOfArgEndsUpInValue
|
|
|
|
|
; OPTALL: [[LD:%[a-zA-Z_0-9-]+]] = load i16* %addr
|
|
|
|
|
|
|
|
|
|
; OPT-NEXT: [[SEXT:%[a-zA-Z_0-9-]+]] = sext i16 [[LD]] to i32
|
|
|
|
|
; OPT-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = add nuw nsw i32 [[SEXT]], zext (i1 icmp ne (i32* getelementptr inbounds ([2 x i32]* @c, i64 0, i64 1), i32* @a) to i32)
|
|
|
|
|
;
|
|
|
|
|
; DISABLE-NEXT: [[ADD:%[a-zA-Z_0-9-]+]] = add nuw nsw i16 [[LD]], zext (i1 icmp ne (i32* getelementptr inbounds ([2 x i32]* @c, i64 0, i64 1), i32* @a) to i16)
|
|
|
|
|
; DISABLE-NEXT: [[RES:%[a-zA-Z_0-9-]+]] = sext i16 [[ADD]] to i32
|
|
|
|
|
;
|
|
|
|
|
; OPTALL-NEXT: ret i32 [[RES]]
|
|
|
|
|
define i32 @promotionOfArgEndsUpInValue(i16* %addr) {
|
|
|
|
|
entry:
|
|
|
|
|
%val = load i16* %addr
|
|
|
|
|
%add = add nuw nsw i16 %val, zext (i1 icmp ne (i32* getelementptr inbounds ([2 x i32]* @c, i64 0, i64 1), i32* @a) to i16)
|
|
|
|
|
%conv3 = sext i16 %add to i32
|
|
|
|
|
ret i32 %conv3
|
|
|
|
|
}
|
