[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