[PATCH] D104282: [FuncSpec] Use std::pow instead of operator^

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 15 00:38:41 PDT 2021


SjoerdMeijer added inline comments.


================
Comment at: llvm/test/Transforms/FunctionSpecialization/function-specialization-loop.ll:2
+; RUN: opt -function-specialization -func-specialization-avg-iters-cost=3 -S < %s | FileCheck %s
+
+; check the bonus for specializing constant arguments are powered by the depth of the loop.
----------------
Just checking, this test didn't trigger before, and now it does? 
If so, would be good to precommit the test, then we can also see the differences better here.


================
Comment at: llvm/test/Transforms/FunctionSpecialization/function-specialization-recursive.ll:41-42
 define i32 @main() {
 ; CHECK-LABEL: @main(
-; CHECK-NEXT:    [[TEMP_I:%.*]] = alloca i32, align 4
-; CHECK-NEXT:    [[TMP1:%.*]] = bitcast i32* [[TEMP_I]] to i8*
-; CHECK-NEXT:    call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull [[TMP1]])
-; CHECK-NEXT:    call void @print_val(i32 1)
-; CHECK-NEXT:    store i32 2, i32* [[TEMP_I]], align 4
-; CHECK-NEXT:    call void @recursiveFunc(i32* nonnull [[TEMP_I]])
-; CHECK-NEXT:    [[TMP2:%.*]] = bitcast i32* [[TEMP_I]] to i8*
-; CHECK-NEXT:    call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull [[TMP2]])
+; CHECK-NEXT:    call void @recursiveFunc(i32* nonnull @Global)
 ; CHECK-NEXT:    ret i32 0
----------------
ChuanqiXu wrote:
> Now it couldn't specialize recursiveFunc due to the change of cost model. I would try to fix it by considering branch condition in getUserBonus.
I don't think it was able to specialise recursive (see also comment at the top). 
I haven't looked very long at this, but something else must have led to different codegen.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104282/new/

https://reviews.llvm.org/D104282



More information about the llvm-commits mailing list