[PATCH] D81026: Inline Cost improvement - GetElementPtr with constant operands

Mircea Trofin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 3 12:39:50 PDT 2020


mtrofin added a comment.

In D81026#2071857 <https://reviews.llvm.org/D81026#2071857>, @apilipenko wrote:

> In D81026#2069624 <https://reviews.llvm.org/D81026#2069624>, @mtrofin wrote:
>
> > That sounds fine, my point is that having some run on benchmarks to quantify the benefit would help understand the value of this particular omission from the cost analysis (or at minimum show there's no regression, or understand where the regressions may be). It could shed important insights into what matters for the cost analysis, basically.
>
>
> The motivation for this change is the sequence generated by our downstream frontend. Essentially we are looking at something like this:
>
>   void foo(ID) {
>     X = constant_table[ID];
>     if (X == some constant) {
>       ...
>     }
>   }
>
> This is a bit oversimplified, but when constant ID is passed into foo it can significantly reduce the cost of inlining. But in order to recognize this we need to recognize a gep of constant operands (the gep is used to compute the address of constant_table[ID]).
>
> Teaching InlineCost to recognize geps of constant operands look like a generic enhancements. If you'd like we can do some performance verification on Clang.


If it's easy, it'd be nice to have. I was mostly concerned with staging it, i.e. having first an easy way to revert in the field, should there be a regression, and then removing that flag later - since adding a flag should be very straight forward.


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

https://reviews.llvm.org/D81026





More information about the llvm-commits mailing list