[PATCH] D30651: [InlineCost, -Oz] Don't take into account the penalty of a fast call of frequently used functions
Evgeny Astigeevich via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 10 09:08:05 PST 2017
eastig added a comment.
I've found an interesting thing related to the cost of getelementptr:
while.cond: ; preds = %while.body, %entry
%dest.addr.0 = phi i8* [ %dest, %entry ], [ %incdec.ptr1, %while.body ]
%src.addr.0 = phi i8* [ %src, %entry ], [ %incdec.ptr, %while.body ]
%tobool = icmp eq i32 %size.addr.0, 0
br i1 %tobool, label %while.end, label %while.body
while.body: ; preds = %while.cond
%dec = add nsw i32 %size.addr.0, -1
%incdec.ptr = getelementptr inbounds i8, i8* %src.addr.0, i32 1
%0 = load i8, i8* %src.addr.0, align 1, !tbaa !12
%incdec.ptr1 = getelementptr inbounds i8, i8* %dest.addr.0, i32 1
store i8 %0, i8* %dest.addr.0, align 1, !tbaa !12
br label %while.cond
while.end: ; preds = %while.cond
Getelementptr instructions have inter-iteration dependencies. CallAnalyzer::visitGetElementPtr returns true for them which means the instructions can be simplified. As a result they don't contribute into the cost of inlining. The instructions are not simplified and are lowered to cost-having instructions.
In fact instructions having inter-iteration dependencies are not so easy to simplify.
Should we have a check of inter-iteration dependencies in CallAnalyzer::visitGetElementPtr?
https://reviews.llvm.org/D30651
More information about the llvm-commits
mailing list