2020-03-26 05:07:03 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
|
|
|
|
|
; RUN: opt -S -early-cse < %s | FileCheck %s --check-prefixes=CHECK,NO_ASSUME
|
2020-06-27 11:41:37 +08:00
|
|
|
; RUN: opt -S -basic-aa -early-cse-memssa < %s | FileCheck %s --check-prefixes=CHECK,NO_ASSUME
|
|
|
|
|
; RUN: opt -S -basic-aa -early-cse-memssa --enable-knowledge-retention < %s | FileCheck %s --check-prefixes=CHECK,USE_ASSUME
|
2019-04-17 12:52:47 +08:00
|
|
|
|
|
|
|
|
declare void @clobber_and_use(i32)
|
|
|
|
|
|
|
|
|
|
define void @f_0(i32* %ptr) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @f_0(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @f_0(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[PTR]], i64 4), "nonnull"(i32* [[PTR]]), "align"(i32* [[PTR]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
|
|
|
|
|
%val0 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val0)
|
|
|
|
|
%val1 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val1)
|
|
|
|
|
%val2 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val2)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @f_1(i32* %ptr) {
|
|
|
|
|
; We can forward invariant loads to non-invariant loads.
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @f_1(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @f_1(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[PTR]], i64 4), "nonnull"(i32* [[PTR]]), "align"(i32* [[PTR]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
|
|
|
|
|
%val0 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val0)
|
|
|
|
|
%val1 = load i32, i32* %ptr
|
|
|
|
|
call void @clobber_and_use(i32 %val1)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @f_2(i32* %ptr) {
|
|
|
|
|
; We can forward a non-invariant load into an invariant load.
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @f_2(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @f_2(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[PTR]], i64 4), "nonnull"(i32* [[PTR]]), "align"(i32* [[PTR]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
|
|
|
|
|
%val0 = load i32, i32* %ptr
|
|
|
|
|
call void @clobber_and_use(i32 %val0)
|
|
|
|
|
%val1 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val1)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @f_3(i1 %cond, i32* %ptr) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @f_3(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: br i1 [[COND:%.*]], label [[LEFT:%.*]], label [[RIGHT:%.*]]
|
|
|
|
|
; NO_ASSUME: left:
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
; NO_ASSUME: right:
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @f_3(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: br i1 [[COND:%.*]], label [[LEFT:%.*]], label [[RIGHT:%.*]]
|
|
|
|
|
; USE_ASSUME: left:
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[PTR]], i64 4), "nonnull"(i32* [[PTR]]), "align"(i32* [[PTR]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
; USE_ASSUME: right:
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
%val0 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val0)
|
|
|
|
|
br i1 %cond, label %left, label %right
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
left:
|
|
|
|
|
%val1 = load i32, i32* %ptr
|
|
|
|
|
call void @clobber_and_use(i32 %val1)
|
|
|
|
|
ret void
|
|
|
|
|
|
|
|
|
|
right:
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define void @f_4(i1 %cond, i32* %ptr) {
|
|
|
|
|
; Negative test -- can't forward %val0 to %va1 because that'll break
|
|
|
|
|
; def-dominates-use.
|
|
|
|
|
; CHECK-LABEL: @f_4(
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-NEXT: br i1 [[COND:%.*]], label [[LEFT:%.*]], label [[MERGE:%.*]]
|
|
|
|
|
; CHECK: left:
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; CHECK-NEXT: [[VAL0:%.*]] = load i32, i32* [[PTR:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-NEXT: call void @clobber_and_use(i32 [[VAL0]])
|
|
|
|
|
; CHECK-NEXT: br label [[MERGE]]
|
|
|
|
|
; CHECK: merge:
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; CHECK-NEXT: [[VAL1:%.*]] = load i32, i32* [[PTR]], align 4
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-NEXT: call void @clobber_and_use(i32 [[VAL1]])
|
|
|
|
|
; CHECK-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
br i1 %cond, label %left, label %merge
|
|
|
|
|
|
|
|
|
|
left:
|
|
|
|
|
|
|
|
|
|
%val0 = load i32, i32* %ptr, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %val0)
|
|
|
|
|
br label %merge
|
|
|
|
|
|
|
|
|
|
merge:
|
|
|
|
|
|
|
|
|
|
%val1 = load i32, i32* %ptr
|
|
|
|
|
call void @clobber_and_use(i32 %val1)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; By assumption, the call can't change contents of p
|
|
|
|
|
; LangRef is a bit unclear about whether the store is reachable, so
|
|
|
|
|
; for the moment we chose to be conservative and just assume it's valid
|
|
|
|
|
; to restore the same unchanging value.
|
|
|
|
|
define void @test_dse1(i32* %p) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @test_dse1(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @test_dse1(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
2020-05-15 05:48:10 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[P]], i64 4), "nonnull"(i32* [[P]]), "align"(i32* [[P]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
%v1 = load i32, i32* %p, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %v1)
|
|
|
|
|
store i32 %v1, i32* %p
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; By assumption, v1 must equal v2 (TODO)
|
|
|
|
|
define void @test_false_negative_dse2(i32* %p, i32 %v2) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-LABEL: @test_false_negative_dse2(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; CHECK-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-NEXT: call void @clobber_and_use(i32 [[V1]])
|
2020-05-15 05:48:10 +08:00
|
|
|
; CHECK-NEXT: store i32 [[V2:%.*]], i32* [[P]], align 4
|
2020-03-26 05:07:03 +08:00
|
|
|
; CHECK-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
%v1 = load i32, i32* %p, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %v1)
|
|
|
|
|
store i32 %v2, i32* %p
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; If we remove the load, we still start an invariant scope since
|
|
|
|
|
; it lets us remove later loads not explicitly marked invariant
|
|
|
|
|
define void @test_scope_start_without_load(i32* %p) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @test_scope_start_without_load(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: [[ADD:%.*]] = add i32 [[V1]], [[V1]]
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[ADD]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @test_scope_start_without_load(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4
|
|
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[P]], i64 4), "nonnull"(i32* [[P]]), "align"(i32* [[P]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: [[ADD:%.*]] = add i32 [[V1]], [[V1]]
|
|
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[ADD]])
|
|
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
%v1 = load i32, i32* %p
|
|
|
|
|
%v2 = load i32, i32* %p, !invariant.load !{}
|
|
|
|
|
%add = add i32 %v1, %v2
|
|
|
|
|
call void @clobber_and_use(i32 %add)
|
|
|
|
|
%v3 = load i32, i32* %p
|
|
|
|
|
call void @clobber_and_use(i32 %v3)
|
|
|
|
|
ret void
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; If we already have an invariant scope, don't want to start a new one
|
|
|
|
|
; with a potentially greater generation. This hides the earlier invariant
|
|
|
|
|
; load
|
|
|
|
|
define void @test_scope_restart(i32* %p) {
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-LABEL: @test_scope_restart(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; NO_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; NO_ASSUME-NEXT: [[ADD:%.*]] = add i32 [[V1]], [[V1]]
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[ADD]])
|
|
|
|
|
; NO_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; NO_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
|
|
|
|
; USE_ASSUME-LABEL: @test_scope_restart(
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: [[V1:%.*]] = load i32, i32* [[P:%.*]], align 4, !invariant.load !0
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
Infer alignment of unmarked loads in IR/bitcode parsing.
For IR generated by a compiler, this is really simple: you just take the
datalayout from the beginning of the file, and apply it to all the IR
later in the file. For optimization testcases that don't care about the
datalayout, this is also really simple: we just use the default
datalayout.
The complexity here comes from the fact that some LLVM tools allow
overriding the datalayout: some tools have an explicit flag for this,
some tools will infer a datalayout based on the code generation target.
Supporting this properly required plumbing through a bunch of new
machinery: we want to allow overriding the datalayout after the
datalayout is parsed from the file, but before we use any information
from it. Therefore, IR/bitcode parsing now has a callback to allow tools
to compute the datalayout at the appropriate time.
Not sure if I covered all the LLVM tools that want to use the callback.
(clang? lli? Misc IR manipulation tools like llvm-link?). But this is at
least enough for all the LLVM regression tests, and IR without a
datalayout is not something frontends should generate.
This change had some sort of weird effects for certain CodeGen
regression tests: if the datalayout is overridden with a datalayout with
a different program or stack address space, we now parse IR based on the
overridden datalayout, instead of the one written in the file (or the
default one, if none is specified). This broke a few AVR tests, and one
AMDGPU test.
Outside the CodeGen tests I mentioned, the test changes are all just
fixing CHECK lines and moving around datalayout lines in weird places.
Differential Revision: https://reviews.llvm.org/D78403
2020-05-15 03:59:45 +08:00
|
|
|
; USE_ASSUME-NEXT: call void @llvm.assume(i1 true) [ "dereferenceable"(i32* [[P]], i64 4), "nonnull"(i32* [[P]]), "align"(i32* [[P]], i64 4) ]
|
2020-03-26 05:07:03 +08:00
|
|
|
; USE_ASSUME-NEXT: [[ADD:%.*]] = add i32 [[V1]], [[V1]]
|
|
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[ADD]])
|
|
|
|
|
; USE_ASSUME-NEXT: call void @clobber_and_use(i32 [[V1]])
|
|
|
|
|
; USE_ASSUME-NEXT: ret void
|
|
|
|
|
;
|
2019-04-17 12:52:47 +08:00
|
|
|
%v1 = load i32, i32* %p, !invariant.load !{}
|
|
|
|
|
call void @clobber_and_use(i32 %v1)
|
|
|
|
|
%v2 = load i32, i32* %p, !invariant.load !{}
|
|
|
|
|
%add = add i32 %v1, %v2
|
|
|
|
|
call void @clobber_and_use(i32 %add)
|
|
|
|
|
%v3 = load i32, i32* %p
|
|
|
|
|
call void @clobber_and_use(i32 %v3)
|
|
|
|
|
ret void
|
|
|
|
|
}
|