================
@@ -1722,6 +1722,11 @@ def int_debugtrap : Intrinsic<[]>,
def int_ubsantrap : Intrinsic<[], [llvm_i8_ty],
[IntrNoReturn, IntrCold, ImmArg<ArgIndex<0>>]>;
+// Return true if profile counter for containing block is hot.
+def int_experimental_hot : Intrinsic<[llvm_i1_ty], [],
+ [IntrInaccessibleMemOnly, IntrWriteMem,
----------------
vitalybuka wrote:
No, we have no more precise attribute. E.g. int_sideeffect is declared this way
as well.
There are a few comments for similar cases around, I'll add one here to.
We need to lock intrinsic in place, without it, it will be moved to the entry
block and value shared between users. So it will work as function level, vs
block level.
With ThinLTO it should not be a problem, in postlink we rerun simplification
and optimization with intrinsic lowered to true or false. I tried to remove
this attribute and make it function level, but can't measure perf difference.
Alternative is to have intrinsic without sideeffects but with dependency like
this:
```
%condition = call i1 @llvm.experimenta.hot(i1 %ubsan_condition)
```
This way we can lock it in place. But this will not help us with assert() with
sideeffects as we discussed before.
So I tried both with UBSAN, ThinLTO and plain, and
```
call i1 @llvm.experimenta.hot()
```
is consistently, but close to noise, faster then:
```
call i1 @llvm.experimenta.hot(i1 %ubsan_condition)
```
I believe because `or i1 %ubsan, @llvm.experimenta.hot()` is more predictable
for early transformation passes than `@llvm.experimenta.hot(i1
%ubsan_condition)`.
Both intrinsic approaches faster then removing traps.
https://github.com/llvm/llvm-project/pull/84850
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
