2014-07-26 05:45:17 +08:00
|
|
|
; RUN: opt < %s -instcombine -S | FileCheck %s
|
|
|
|
|
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
|
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
define i32 @foo1(i32* %a) #0 {
|
|
|
|
|
entry:
|
2015-02-28 05:17:42 +08:00
|
|
|
%0 = load i32, i32* %a, align 4
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
|
|
|
|
|
; Check that the alignment has been upgraded and that the assume has not
|
|
|
|
|
; been removed:
|
|
|
|
|
; CHECK-LABEL: @foo1
|
2015-02-28 05:17:42 +08:00
|
|
|
; CHECK-DAG: load i32, i32* %a, align 32
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK-DAG: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32
|
|
|
|
|
|
|
|
|
|
%ptrint = ptrtoint i32* %a to i64
|
|
|
|
|
%maskedptr = and i64 %ptrint, 31
|
|
|
|
|
%maskcond = icmp eq i64 %maskedptr, 0
|
|
|
|
|
tail call void @llvm.assume(i1 %maskcond)
|
|
|
|
|
|
|
|
|
|
ret i32 %0
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @foo2(i32* %a) #0 {
|
|
|
|
|
entry:
|
|
|
|
|
; Same check as in @foo1, but make sure it works if the assume is first too.
|
|
|
|
|
; CHECK-LABEL: @foo2
|
2015-02-28 05:17:42 +08:00
|
|
|
; CHECK-DAG: load i32, i32* %a, align 32
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK-DAG: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32
|
|
|
|
|
|
|
|
|
|
%ptrint = ptrtoint i32* %a to i64
|
|
|
|
|
%maskedptr = and i64 %ptrint, 31
|
|
|
|
|
%maskcond = icmp eq i64 %maskedptr, 0
|
|
|
|
|
tail call void @llvm.assume(i1 %maskcond)
|
|
|
|
|
|
2015-02-28 05:17:42 +08:00
|
|
|
%0 = load i32, i32* %a, align 4
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ret i32 %0
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-26 05:45:17 +08:00
|
|
|
declare void @llvm.assume(i1) #1
|
|
|
|
|
|
2014-09-08 05:28:34 +08:00
|
|
|
define i32 @simple(i32 %a) #1 {
|
|
|
|
|
entry:
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: @simple
|
|
|
|
|
; CHECK: call void @llvm.assume
|
|
|
|
|
; CHECK: ret i32 4
|
|
|
|
|
|
|
|
|
|
%cmp = icmp eq i32 %a, 4
|
2016-12-19 16:22:17 +08:00
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
2014-09-08 05:28:34 +08:00
|
|
|
ret i32 %a
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-26 05:45:17 +08:00
|
|
|
define i32 @can1(i1 %a, i1 %b, i1 %c) {
|
|
|
|
|
entry:
|
|
|
|
|
%and1 = and i1 %a, %b
|
|
|
|
|
%and = and i1 %and1, %c
|
|
|
|
|
tail call void @llvm.assume(i1 %and)
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: @can1
|
|
|
|
|
; CHECK: call void @llvm.assume(i1 %a)
|
|
|
|
|
; CHECK: call void @llvm.assume(i1 %b)
|
|
|
|
|
; CHECK: call void @llvm.assume(i1 %c)
|
|
|
|
|
; CHECK: ret i32
|
|
|
|
|
|
|
|
|
|
ret i32 5
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @can2(i1 %a, i1 %b, i1 %c) {
|
|
|
|
|
entry:
|
|
|
|
|
%v = or i1 %a, %b
|
|
|
|
|
%w = xor i1 %v, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %w)
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: @can2
|
|
|
|
|
; CHECK: %[[V1:[^ ]+]] = xor i1 %a, true
|
|
|
|
|
; CHECK: call void @llvm.assume(i1 %[[V1]])
|
|
|
|
|
; CHECK: %[[V2:[^ ]+]] = xor i1 %b, true
|
|
|
|
|
; CHECK: call void @llvm.assume(i1 %[[V2]])
|
|
|
|
|
; CHECK: ret i32
|
|
|
|
|
|
|
|
|
|
ret i32 5
|
|
|
|
|
}
|
|
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
define i32 @bar1(i32 %a) #0 {
|
|
|
|
|
entry:
|
|
|
|
|
%and1 = and i32 %a, 3
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: @bar1
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32 1
|
|
|
|
|
|
|
|
|
|
%and = and i32 %a, 7
|
|
|
|
|
%cmp = icmp eq i32 %and, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
|
|
|
|
|
ret i32 %and1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @bar2(i32 %a) #0 {
|
|
|
|
|
entry:
|
|
|
|
|
; CHECK-LABEL: @bar2
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32 1
|
|
|
|
|
|
|
|
|
|
%and = and i32 %a, 7
|
|
|
|
|
%cmp = icmp eq i32 %and, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
|
|
|
|
|
%and1 = and i32 %a, 3
|
|
|
|
|
ret i32 %and1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @bar3(i32 %a, i1 %x, i1 %y) #0 {
|
|
|
|
|
entry:
|
|
|
|
|
%and1 = and i32 %a, 3
|
|
|
|
|
|
|
|
|
|
; Don't be fooled by other assumes around.
|
|
|
|
|
; CHECK-LABEL: @bar3
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32 1
|
|
|
|
|
|
|
|
|
|
tail call void @llvm.assume(i1 %x)
|
|
|
|
|
|
|
|
|
|
%and = and i32 %a, 7
|
|
|
|
|
%cmp = icmp eq i32 %and, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
|
|
|
|
|
tail call void @llvm.assume(i1 %y)
|
|
|
|
|
|
|
|
|
|
ret i32 %and1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @bar4(i32 %a, i32 %b) {
|
|
|
|
|
entry:
|
|
|
|
|
%and1 = and i32 %b, 3
|
|
|
|
|
|
|
|
|
|
; CHECK-LABEL: @bar4
|
2016-12-19 16:22:17 +08:00
|
|
|
; CHECK: call void @llvm.assume
|
|
|
|
|
; CHECK: call void @llvm.assume
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
; CHECK: ret i32 1
|
|
|
|
|
|
|
|
|
|
%and = and i32 %a, 7
|
|
|
|
|
%cmp = icmp eq i32 %and, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
|
|
|
|
|
%cmp2 = icmp eq i32 %a, %b
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp2)
|
|
|
|
|
|
|
|
|
|
ret i32 %and1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @icmp1(i32 %a) #0 {
|
2017-01-10 03:43:26 +08:00
|
|
|
; CHECK-LABEL: @icmp1(
|
|
|
|
|
; CHECK-NEXT: [[CMP:%.*]] = icmp sgt i32 [[A:%.*]], 5
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 [[CMP]])
|
|
|
|
|
; CHECK-NEXT: ret i32 1
|
|
|
|
|
;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
%cmp = icmp sgt i32 %a, 5
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
%conv = zext i1 %cmp to i32
|
|
|
|
|
ret i32 %conv
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define i32 @icmp2(i32 %a) #0 {
|
2017-01-10 03:43:26 +08:00
|
|
|
; CHECK-LABEL: @icmp2(
|
|
|
|
|
; CHECK-NEXT: [[CMP:%.*]] = icmp sgt i32 [[A:%.*]], 5
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 [[CMP]])
|
|
|
|
|
; CHECK-NEXT: ret i32 0
|
|
|
|
|
;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
%cmp = icmp sgt i32 %a, 5
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
2017-01-10 03:43:26 +08:00
|
|
|
%t0 = zext i1 %cmp to i32
|
|
|
|
|
%lnot.ext = xor i32 %t0, 1
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ret i32 %lnot.ext
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-18 02:15:49 +08:00
|
|
|
; If the 'not' of a condition is known true, then the condition must be false.
|
2017-01-10 04:18:30 +08:00
|
|
|
|
|
|
|
|
define i1 @assume_not(i1 %cond) {
|
|
|
|
|
; CHECK-LABEL: @assume_not(
|
|
|
|
|
; CHECK-NEXT: [[NOTCOND:%.*]] = xor i1 [[COND:%.*]], true
|
|
|
|
|
; CHECK-NEXT: call void @llvm.assume(i1 [[NOTCOND]])
|
2017-01-18 02:15:49 +08:00
|
|
|
; CHECK-NEXT: ret i1 false
|
2017-01-10 04:18:30 +08:00
|
|
|
;
|
|
|
|
|
%notcond = xor i1 %cond, true
|
|
|
|
|
call void @llvm.assume(i1 %notcond)
|
|
|
|
|
ret i1 %cond
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
declare void @escape(i32* %a)
|
|
|
|
|
|
2017-01-04 03:32:11 +08:00
|
|
|
; Canonicalize a nonnull assumption on a load into metadata form.
|
|
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
define i1 @nonnull1(i32** %a) {
|
2017-01-04 03:32:11 +08:00
|
|
|
; CHECK-LABEL: @nonnull1(
|
|
|
|
|
; CHECK-NEXT: [[LOAD:%.*]] = load i32*, i32** %a, align 8, !nonnull !0
|
|
|
|
|
; CHECK-NEXT: tail call void @escape(i32* nonnull [[LOAD]])
|
|
|
|
|
; CHECK-NEXT: ret i1 false
|
|
|
|
|
;
|
2015-02-28 05:17:42 +08:00
|
|
|
%load = load i32*, i32** %a
|
2014-11-12 07:33:19 +08:00
|
|
|
%cmp = icmp ne i32* %load, null
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
tail call void @escape(i32* %load)
|
|
|
|
|
%rval = icmp eq i32* %load, null
|
|
|
|
|
ret i1 %rval
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Make sure the above canonicalization applies only
|
|
|
|
|
; to pointer types. Doing otherwise would be illegal.
|
2017-01-04 03:32:11 +08:00
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
define i1 @nonnull2(i32* %a) {
|
2017-01-04 03:32:11 +08:00
|
|
|
; CHECK-LABEL: @nonnull2(
|
|
|
|
|
; CHECK-NEXT: [[LOAD:%.*]] = load i32, i32* %a, align 4
|
|
|
|
|
; CHECK-NEXT: [[CMP:%.*]] = icmp ne i32 [[LOAD]], 0
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 [[CMP]])
|
|
|
|
|
; CHECK-NEXT: [[RVAL:%.*]] = icmp eq i32 [[LOAD]], 0
|
|
|
|
|
; CHECK-NEXT: ret i1 [[RVAL]]
|
|
|
|
|
;
|
2015-02-28 05:17:42 +08:00
|
|
|
%load = load i32, i32* %a
|
2014-11-12 07:33:19 +08:00
|
|
|
%cmp = icmp ne i32 %load, 0
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
%rval = icmp eq i32 %load, 0
|
|
|
|
|
ret i1 %rval
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Make sure the above canonicalization does not trigger
|
|
|
|
|
; if the assume is control dependent on something else
|
2017-01-04 03:32:11 +08:00
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
define i1 @nonnull3(i32** %a, i1 %control) {
|
2017-01-04 03:32:11 +08:00
|
|
|
; CHECK-LABEL: @nonnull3(
|
|
|
|
|
; CHECK-NEXT: entry:
|
|
|
|
|
; CHECK-NEXT: [[LOAD:%.*]] = load i32*, i32** %a, align 8
|
|
|
|
|
; CHECK-NEXT: br i1 %control, label %taken, label %not_taken
|
|
|
|
|
; CHECK: taken:
|
|
|
|
|
; CHECK-NEXT: [[CMP:%.*]] = icmp ne i32* [[LOAD]], null
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 [[CMP]])
|
|
|
|
|
; CHECK-NEXT: [[RVAL:%.*]] = icmp eq i32* [[LOAD]], null
|
|
|
|
|
; CHECK-NEXT: ret i1 [[RVAL]]
|
|
|
|
|
; CHECK: not_taken:
|
|
|
|
|
; CHECK-NEXT: ret i1 true
|
|
|
|
|
;
|
2014-11-12 07:33:19 +08:00
|
|
|
entry:
|
2015-02-28 05:17:42 +08:00
|
|
|
%load = load i32*, i32** %a
|
2014-11-12 07:33:19 +08:00
|
|
|
%cmp = icmp ne i32* %load, null
|
|
|
|
|
br i1 %control, label %taken, label %not_taken
|
|
|
|
|
taken:
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
%rval = icmp eq i32* %load, null
|
|
|
|
|
ret i1 %rval
|
|
|
|
|
not_taken:
|
|
|
|
|
ret i1 true
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
; Make sure the above canonicalization does not trigger
|
2017-01-04 03:32:11 +08:00
|
|
|
; if the path from the load to the assume is potentially
|
2014-11-12 07:33:19 +08:00
|
|
|
; interrupted by an exception being thrown
|
2017-01-04 03:32:11 +08:00
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
define i1 @nonnull4(i32** %a) {
|
2017-01-04 03:32:11 +08:00
|
|
|
; CHECK-LABEL: @nonnull4(
|
|
|
|
|
; CHECK-NEXT: [[LOAD:%.*]] = load i32*, i32** %a, align 8
|
|
|
|
|
; CHECK-NEXT: tail call void @escape(i32* [[LOAD]])
|
|
|
|
|
; CHECK-NEXT: [[CMP:%.*]] = icmp ne i32* [[LOAD]], null
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 [[CMP]])
|
|
|
|
|
; CHECK-NEXT: [[RVAL:%.*]] = icmp eq i32* [[LOAD]], null
|
|
|
|
|
; CHECK-NEXT: ret i1 [[RVAL]]
|
|
|
|
|
;
|
2015-02-28 05:17:42 +08:00
|
|
|
%load = load i32*, i32** %a
|
2014-11-12 07:33:19 +08:00
|
|
|
;; This call may throw!
|
|
|
|
|
tail call void @escape(i32* %load)
|
|
|
|
|
%cmp = icmp ne i32* %load, null
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
%rval = icmp eq i32* %load, null
|
|
|
|
|
ret i1 %rval
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-10 02:56:03 +08:00
|
|
|
; PR35846 - https://bugs.llvm.org/show_bug.cgi?id=35846
|
|
|
|
|
|
|
|
|
|
define i32 @assumption_conflicts_with_known_bits(i32 %a, i32 %b) {
|
|
|
|
|
; CHECK-LABEL: @assumption_conflicts_with_known_bits(
|
|
|
|
|
; CHECK-NEXT: tail call void @llvm.assume(i1 false)
|
|
|
|
|
; CHECK-NEXT: ret i32 0
|
|
|
|
|
;
|
|
|
|
|
%and1 = and i32 %b, 3
|
|
|
|
|
%B1 = lshr i32 %and1, %and1
|
|
|
|
|
%B3 = shl nuw nsw i32 %and1, %B1
|
|
|
|
|
%cmp = icmp eq i32 %B3, 1
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp)
|
|
|
|
|
%cmp2 = icmp eq i32 %B1, %B3
|
|
|
|
|
tail call void @llvm.assume(i1 %cmp2)
|
|
|
|
|
ret i32 %and1
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-12 07:33:19 +08:00
|
|
|
|
2014-07-26 05:45:17 +08:00
|
|
|
attributes #0 = { nounwind uwtable }
|
|
|
|
|
attributes #1 = { nounwind }
|
|
|
|
|
|