thr3ads.net - llvm dev - [llvm-dev] Conditional analysis before inliner [Apr 2018]

If this information is useful, please help other people find it:
Share via:

Anom LLVM via llvm-dev

2018-Apr-23 22:37 UTC

[llvm-dev] Conditional analysis before inliner

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>

Friedman, Eli via llvm-dev

2018-Apr-23 23:02 UTC

head link

[llvm-dev] Conditional analysis before inliner

I probably wouldn't worry about the cost of LoopInfo; it's relatively 
cheap to compute.  But if you're really concerned, you can run your pass 
after a pass which preserves LoopInfo (so it's free because it was 
already computed).  Or you can stick your code into an existing pass 
which requires LoopInfo anyway, like LoopIdiomRecognize.

-Eli

On 4/23/2018 3:37 PM, Anom LLVM wrote:> 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 <mailto: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
>
>
-- 
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/5f85a4a8/attachment.html>

Jatin Bhateja via llvm-dev

2018-Apr-28 06:41 UTC

head link

[llvm-dev] Conditional analysis before inliner

I do not think we have this framework of conditionally kicking in analysis
passes. But one can always do "intelligent" prior setting of attribute
over
function which can be checked in getAnalysisUsage for a perticular pass to
conditionally enable needed analysis.

Cheers
Jatin

On Tue, 24 Apr 2018, 04:33 Friedman, Eli via llvm-dev, <
llvm-dev at lists.llvm.org> wrote:
> I probably wouldn't worry about the cost of LoopInfo; it's
relatively
> cheap to compute.  But if you're really concerned, you can run your
pass
> after a pass which preserves LoopInfo (so it's free because it was
already
> computed).  Or you can stick your code into an existing pass which requires
> LoopInfo anyway, like LoopIdiomRecognize.
>
> -Eli
>
> On 4/23/2018 3:37 PM, Anom LLVM wrote:
>
> 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
>>
>>
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180428/e6b46668/attachment.html>

Reasonably Related Threads

Search for more possibly parallel threads

llvm dev - Apr 2018 - Conditional analysis before inliner

[llvm-dev] Conditional analysis before inliner

[llvm-dev] Conditional analysis before inliner

[llvm-dev] Conditional analysis before inliner

Reasonably Related Threads