XChy wrote:
> Optimization pipeline is doing simplifications and canonicalizations. If you
> for example use `-target amdcgn`, then I think you will see that the codegen
> is impacted negatively when not simplifying the control flow. So it depends
> on the backend if one form is profitable or
XChy wrote:
> Here is another thing that I noticed after this patch:
> https://godbolt.org/z/1P7bnKGjh
>
> So early instcombine is eliminating an `and` operation (in the foo example),
> resulting in simplifycfg not being able to collapse the control flow any
> longer.
I don't think it's a
eddyz87 wrote:
Some additional details on BPF verifier failure.
Consider the following example:
```llvm
@a = global i32 0, align 4
@g = global i32 0, align 4
define i64 @foo() {
entry:
%a = load i32, ptr @a
%a.cmp = icmp ugt i32 %a, 32
br i1 %a.cmp, label %end, label %l1 ; establish %a
nikic wrote:
@bjope It looks like the InstCombine changes enable IndVars to perform LFTR,
which is unprofitable in this case. Though the `umax(1)` call is actually
completely unnecessary here, but SCEV doesn't realize it. I've put up
https://github.com/llvm/llvm-project/pull/75039 to fix
bjope wrote:
Is the behavior seen in this example expected?
https://godbolt.org/z/f8eqEnsq6
The comments in InstCombineCompares kind of indicates that you try to avoid
changing a signed predicate to a unsigned. But isn't that what happens here. As
well as increasing the instruction count
metaflow wrote:
looks like we just had a pathological case that was on a threshold. Thank you!
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
metaflow wrote:
heads up - we see a much larger regression for one of the cases in TensorFlow
(trying to confirm it)
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw approved this pull request.
The regression in `Shootout-C++-ary2` may be caused by ThinLTO. But I think it
is OK to go ahead and merge :)
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
nikic wrote:
Rebased over the SCEV change. @dtcxzyw Can you please give it another try?
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
The problem for mpeg2decode seems to be that we do more `add` to `or disjoint`
conversions. But `or disjoint` is still being implemented, so e.g. in SCEV we
don't recognize it yet and fail to create an `add` SCEV for it. So I think we
need to do some more work on `or disjoint`
dtcxzyw wrote:
Looks like the regression in `DILATE` has been addressed.
Could you please have a look at
`MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode`?
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
nikic wrote:
I went ahead and pushed a clean up version of that change to this PR, so you
can just re-test this PR.
I've found that dropping the icmp case also removes most of the second-order
compile-time regressions, and also drops the (very minor) regression in the BPF
test, so those are
nikic wrote:
@dtcxzyw Could you please run another test with this branch?
https://github.com/nikic/llvm-project/tree/perf/dom-cond-3
I believe the issue with DILATE is that we have some icmps that get
canonicalized from signed to unsigned predicate, and IndVars is not able to
perform some
dtcxzyw wrote:
Could you please rebase this patch on
https://github.com/llvm/llvm-project/pull/74246 and add a test for
https://github.com/llvm/llvm-project/issues/74242?
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
@@ -16,11 +16,15 @@ define i32 @test_asr(i32 %a, i32 %b) {
; CHECK-NEXT:[[C:%.*]] = icmp slt i32 [[A]], 0
; CHECK-NEXT:br i1 [[C]], label [[BB2:%.*]], label [[BB3:%.*]]
; CHECK: bb2:
+; CHECK-NEXT:[[NOT:%.*]] = xor i32 [[A]], -1
+; CHECK-NEXT:[[D:%.*]] =
@@ -16,11 +16,15 @@ define i32 @test_asr(i32 %a, i32 %b) {
; CHECK-NEXT:[[C:%.*]] = icmp slt i32 [[A]], 0
; CHECK-NEXT:br i1 [[C]], label [[BB2:%.*]], label [[BB3:%.*]]
; CHECK: bb2:
+; CHECK-NEXT:[[NOT:%.*]] = xor i32 [[A]], -1
+; CHECK-NEXT:[[D:%.*]] =
@@ -0,0 +1,74 @@
+//===- DomConditionCache.cpp
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
@@ -16,11 +16,15 @@ define i32 @test_asr(i32 %a, i32 %b) {
; CHECK-NEXT:[[C:%.*]] = icmp slt i32 [[A]], 0
; CHECK-NEXT:br i1 [[C]], label [[BB2:%.*]], label [[BB3:%.*]]
; CHECK: bb2:
+; CHECK-NEXT:[[NOT:%.*]] = xor i32 [[A]], -1
+; CHECK-NEXT:[[D:%.*]] =
@@ -75,7 +75,8 @@ define void @idom_sign_bit_check_edge_dominates_select(i64
%a, i64 %b) {
; CHECK: land.lhs.true:
; CHECK-NEXT:br label [[LOR_END:%.*]]
; CHECK: lor.rhs:
-; CHECK-NEXT:[[CMP3_NOT:%.*]] = icmp eq i64 [[A]], [[B:%.*]]
+; CHECK-NEXT:
@@ -16,11 +16,15 @@ define i32 @test_asr(i32 %a, i32 %b) {
; CHECK-NEXT:[[C:%.*]] = icmp slt i32 [[A]], 0
; CHECK-NEXT:br i1 [[C]], label [[BB2:%.*]], label [[BB3:%.*]]
; CHECK: bb2:
+; CHECK-NEXT:[[NOT:%.*]] = xor i32 [[A]], -1
+; CHECK-NEXT:[[D:%.*]] =
@@ -75,7 +75,8 @@ define void @idom_sign_bit_check_edge_dominates_select(i64
%a, i64 %b) {
; CHECK: land.lhs.true:
; CHECK-NEXT:br label [[LOR_END:%.*]]
; CHECK: lor.rhs:
-; CHECK-NEXT:[[CMP3_NOT:%.*]] = icmp eq i64 [[A]], [[B:%.*]]
+; CHECK-NEXT:
@@ -0,0 +1,74 @@
+//===- DomConditionCache.cpp
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
nikic wrote:
Just realized that this doesn't cover uses of isKnownNonNegative() in
InstCombine yet, as it currently doesn't go through SimplifyQuery. I'll see
about migrating those APIs tomorrow.
https://github.com/llvm/llvm-project/pull/73662
___
24 matches
Mail list logo
