llvm dev - Apr 2018 - Conditional analysis before inliner

Hi,

I have pass phase ordering question.

I am interested in performing a transformation that matches several LLVM IR
instructions and converts them to a single builtin. This sort of
transformation must occur prior to inlining because inlining needs to
analyze cost of the builtin. However, the LLVM IR -> builtin transformation
requires scalar evolution which typically doesn't run until after the
inliner.

My question is, is there a way to run scalar evolution conditionally prior
to inlining? I'd like to leave compile time unaffected if my code
doesn't
contain any of these builtins.

Thanks,

Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180419/9c081b19/attachment.html>

On 4/19/2018 1:57 PM, Anom LLVM via llvm-dev wrote:
> Hi,
>
> I have pass phase ordering question.
>
> I am interested in performing a transformation that matches several 
> LLVM IR instructions and converts them to a single builtin. This sort 
> of transformation must occur prior to inlining because inlining needs 
> to analyze cost of the builtin. However, the LLVM IR -> builtin 
> transformation requires scalar evolution which typically doesn't run 
> until after the inliner.
This isn't right, or at least, not the complete picture; loop 
optimization passes run interleaved with the inliner.  (Try looking at 
the output of "-debug-pass=Executions" to see exactly what's
happening.)
> My question is, is there a way to run scalar evolution conditionally 
> prior to inlining? I'd like to leave compile time unaffected if my 
> code doesn't contain any of these builtins.
ScalarEvolution is lazy, so it's essentially free if you don't query it.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

Thanks for the answer Eli.

I think I was a little too vague in my question. The program has the
following structure:
void foo() {
  bar();
}

void bar() {
  for (..) {
       __builtin_compute()
  }
}

We would like to use scalar evolution + loopinfowrapperpass inside
instcombine only if __builtin_compute is present. instcombine can convert
the loop into a single builtin ie.

void bar() {
  __builtin_wide_compute();
}

When the inliner runs on foo(), we want bar() to already have the
transformation to reflect the cost of the inlining decision more
accurately.

I do see that scalar evolution is a lazy but loopwrapinfopass is not. Is
there a way to run these two analysis passes conditionally before inlining?

Thanks,

Stan






On Fri, Apr 20, 2018 at 1:55 PM, Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> On 4/19/2018 1:57 PM, Anom LLVM via llvm-dev wrote:
>
>> Hi,
>>
>> I have pass phase ordering question.
>>
>> I am interested in performing a transformation that matches several
LLVM
>> IR instructions and converts them to a single builtin. This sort of
>> transformation must occur prior to inlining because inlining needs to
>> analyze cost of the builtin. However, the LLVM IR -> builtin
transformation
>> requires scalar evolution which typically doesn't run until after
the
>> inliner.
>>
>
> This isn't right, or at least, not the complete picture; loop
optimization
> passes run interleaved with the inliner.  (Try looking at the output of
> "-debug-pass=Executions" to see exactly what's happening.)
>
> My question is, is there a way to run scalar evolution conditionally prior
>> to inlining? I'd like to leave compile time unaffected if my code
doesn't
>> contain any of these builtins.
>>
>
> ScalarEvolution is lazy, so it's essentially free if you don't
query it.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180423/eb073e94/attachment.html>