minglotus-6 wrote:
> The invoke instruction can have 3 different kinds of prof data
>
> 1. call count (if a direct call)
> 2. VP profile data (if an indirect call)
> 3. branch weights for landing pad.
> 4. can coexist with 2) and does not need to be updated. Is there an existing
> test
https://github.com/minglotus-6 updated
https://github.com/llvm/llvm-project/pull/83809
>From 9575b83ea40012ecbfbf301a24ec89de0726ffd4 Mon Sep 17 00:00:00 2001
From: mingmingl
Date: Mon, 4 Mar 2024 00:43:55 -0800
Subject: [PATCH] update profile for invoke instruction in caller and callee
after
minglotus-6 wrote:
> The invoke instruction can have 3 different kinds of prof data
>
> 1. call count (if a direct call)
> 2. VP profile data (if an indirect call)
> 3. branch weights for landing pad.
> 4. can coexist with 2) and does not need to be updated.
thanks for the list. I get the
https://github.com/david-xl commented:
The invoke instruction can have 3 different kinds of prof data
1) call count (if a direct call)
2) VP profile data (if an indirect call)
3) branch weights for landing pad.
3) can coexist with 2) and does not need to be updated. Is there an existing
test
@@ -918,6 +918,18 @@ LandingPadInst *InvokeInst::getLandingPadInst() const {
return cast(getUnwindDest()->getFirstNonPHI());
}
+void InvokeInst::updateProfWeight(uint64_t S, uint64_t T) {
minglotus-6 wrote:
> Is there a reason why branch weight !prof
@@ -918,6 +918,18 @@ LandingPadInst *InvokeInst::getLandingPadInst() const {
return cast(getUnwindDest()->getFirstNonPHI());
}
+void InvokeInst::updateProfWeight(uint64_t S, uint64_t T) {
minglotus-6 wrote:
also from
@@ -918,6 +918,18 @@ LandingPadInst *InvokeInst::getLandingPadInst() const {
return cast(getUnwindDest()->getFirstNonPHI());
}
+void InvokeInst::updateProfWeight(uint64_t S, uint64_t T) {
minglotus-6 wrote:
@@ -918,6 +918,18 @@ LandingPadInst *InvokeInst::getLandingPadInst() const {
return cast(getUnwindDest()->getFirstNonPHI());
}
+void InvokeInst::updateProfWeight(uint64_t S, uint64_t T) {
minglotus-6 wrote:
It makes sense to move them to `CallBase`. Will
@@ -918,6 +918,18 @@ LandingPadInst *InvokeInst::getLandingPadInst() const {
return cast(getUnwindDest()->getFirstNonPHI());
}
+void InvokeInst::updateProfWeight(uint64_t S, uint64_t T) {
david-xl wrote:
should this be moved to CallBase?
@@ -0,0 +1,185 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: --version 4
+
+; RUN: opt < %s -passes='require,cgscc(inline)'
-inline-threshold=1000 -S | FileCheck %s
+
+target datalayout =
llvmbot wrote:
@llvm/pr-subscribers-llvm-ir
Author: Mingming Liu (minglotus-6)
Changes
A related change is https://reviews.llvm.org/D133121, which correctly
preserves both branch weights and value profiles for invoke instruction.
* The parent nfc commit is
https://github.com/minglotus-6 ready_for_review
https://github.com/llvm/llvm-project/pull/83809
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/minglotus-6 edited
https://github.com/llvm/llvm-project/pull/83809
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/minglotus-6 edited
https://github.com/llvm/llvm-project/pull/83809
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/minglotus-6 created
https://github.com/llvm/llvm-project/pull/83809
None
>From 9575b83ea40012ecbfbf301a24ec89de0726ffd4 Mon Sep 17 00:00:00 2001
From: mingmingl
Date: Mon, 4 Mar 2024 00:43:55 -0800
Subject: [PATCH] update profile for invoke instruction in caller and callee
15 matches
Mail list logo
