Jun Lim via llvm-dev
2017-Oct-03 16:21 UTC
[llvm-dev] General question about enabling partial inlining
Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2. Would it make sense to give some bonus in the cost model when we detect the possibility of spilling CSRs in the entry block? Thanks, Jun From: Graham Yiu [mailto:gyiu at ca.ibm.com] Sent: Tuesday, October 3, 2017 11:08 AM To: junbuml at codeaurora.org Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] General question about enabling partial inlining Hi Jun, We're actually looking at enhancing the partial inlining pass right now (see <http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html) We'd be interested in turning on the pass by default some time in the future, if our enhancements prove beneficial. Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com <mailto:gyiu at ca.ibm.com> via llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains in some spec benchmarks without From: via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Date: 09/13/2017 01:12 PM Subject: [llvm-dev] General question about enabling partial inlining Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org> > _____ Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works to enable partial inlining ? Thanks, Jun -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin _mailman_listinfo_llvm-2Ddev <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbi n_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0 GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknk n0Ts3R_e3PU64h_dyvEkyCdonAVo&e=> &d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZq I-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo& e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/043a505d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/043a505d/attachment.gif>
Graham Yiu via llvm-dev
2017-Oct-03 16:45 UTC
[llvm-dev] General question about enabling partial inlining
Hi Jun, If we were to enable this by default, I think we'd make a push to enable it with or without PGO. I'm not sure what's currently preventing the partial inlining pass to be enabled by default, actually. David Li may have a better sense on this as he's been actively working on it most recently. As for the cost model, right now it's platform independent, so I'm assuming you'll need some sort of hook for platform-specific costs/bonuses to detect spilling of different types of registers. Also, I'm not quite sure how you'll do this type of detection at the IR level. Are you thinking some sort of heuristic? Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: "Jun Lim" <junbuml at codeaurora.org> To: "'Graham Yiu'" <gyiu at ca.ibm.com> Cc: <llvm-dev at lists.llvm.org> Date: 10/03/2017 12:21 PM Subject: RE: [llvm-dev] General question about enabling partial inlining Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2. Would it make sense to give some bonus in the cost model when we detect the possibility of spilling CSRs in the entry block? Thanks, Jun From: Graham Yiu [mailto:gyiu at ca.ibm.com] Sent: Tuesday, October 3, 2017 11:08 AM To: junbuml at codeaurora.org Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] General question about enabling partial inlining Hi Jun, We're actually looking at enhancing the partial inlining pass right now (see http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html) We'd be interested in turning on the pass by default some time in the future, if our enhancements prove beneficial. Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com Inactive hide details for via llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains in some spec benchmarksvia llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains in some spec benchmarks without From: via llvm-dev <llvm-dev at lists.llvm.org> To: llvm-dev at lists.llvm.org Date: 09/13/2017 01:12 PM Subject: [llvm-dev] General question about enabling partial inlining Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org> Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works to enable partial inlining ? Thanks, Jun -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo&e -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/efc3d974/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/efc3d974/attachment-0001.gif>
Jun Lim via llvm-dev
2017-Oct-03 17:06 UTC
[llvm-dev] General question about enabling partial inlining
> As for the cost model, right now it's platform independent, so I'massuming you'll need some sort of hook for platform-specific costs/bonuses to detect spilling of different types of registers. Also, I'm not quite sure how you'll do this type of detection at the IR level. Are you thinking some sort of heuristic? Agree, it should be a target specific hook if doing so make sense. As far as I see the CSRCost used in RegAllocGreedy is extremely low, so in most cases we allocate a CSR if a live range expand across a function call. I guess we can estimate this by checking if a user of a value defined in the entry block is reachable from a block with a function call. From: Graham Yiu [mailto:gyiu at ca.ibm.com] Sent: Tuesday, October 3, 2017 12:45 PM To: Jun Lim <junbuml at codeaurora.org> Cc: llvm-dev at lists.llvm.org Subject: RE: [llvm-dev] General question about enabling partial inlining Hi Jun, If we were to enable this by default, I think we'd make a push to enable it with or without PGO. I'm not sure what's currently preventing the partial inlining pass to be enabled by default, actually. David Li may have a better sense on this as he's been actively working on it most recently. As for the cost model, right now it's platform independent, so I'm assuming you'll need some sort of hook for platform-specific costs/bonuses to detect spilling of different types of registers. Also, I'm not quite sure how you'll do this type of detection at the IR level. Are you thinking some sort of heuristic? Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com <mailto:gyiu at ca.ibm.com> "Jun Lim" ---10/03/2017 12:21:38 PM---Hi Graham, From: "Jun Lim" <junbuml at codeaurora.org <mailto:junbuml at codeaurora.org> > To: "'Graham Yiu'" <gyiu at ca.ibm.com <mailto:gyiu at ca.ibm.com> > Cc: <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > Date: 10/03/2017 12:21 PM Subject: RE: [llvm-dev] General question about enabling partial inlining _____ Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2. Would it make sense to give some bonus in the cost model when we detect the possibility of spilling CSRs in the entry block? Thanks, Jun From: Graham Yiu [mailto:gyiu at ca.ibm.com] Sent: Tuesday, October 3, 2017 11:08 AM To: junbuml at codeaurora.org <mailto:junbuml at codeaurora.org> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] General question about enabling partial inlining Hi Jun, We're actually looking at enhancing the partial inlining pass right now (see <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermai l_llvm-2Ddev_2017-2DAugust_116515.html&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4 ST7e3kMd0GTi3w9ByK5Cw&m=9oYOvB3l33-euX7ag6texitDSABCTLWfauz0YGW7zZ8&s=lZOJDe oavpuEHo29CLd9Kvkn1ibSdgK5125f13O-LYQ&e=> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html) We'd be interested in turning on the pass by default some time in the future, if our enhancements prove beneficial. Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: <mailto:gyiu at ca.ibm.com> gyiu at ca.ibm.com via llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains in some spec benchmarks without From: via llvm-dev < <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org> To: <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org Date: 09/13/2017 01:12 PM Subject: [llvm-dev] General question about enabling partial inlining Sent by: "llvm-dev" < <mailto:llvm-dev-bounces at lists.llvm.org> llvm-dev-bounces at lists.llvm.org> _____ Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works to enable partial inlining ? Thanks, Jun -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ LLVM Developers mailing list <mailto:llvm-dev at lists.llvm.org> llvm-dev at lists.llvm.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbi n_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0 GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknk n0Ts3R_e3PU64h_dyvEkyCdonAVo&e=> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin _mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0G Ti3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn 0Ts3R_e3PU64h_dyvEkyCdonAVo&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/90e1fa8b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/90e1fa8b/attachment.gif>
Xinliang David Li via llvm-dev
2017-Oct-03 19:22 UTC
[llvm-dev] General question about enabling partial inlining
On Tue, Oct 3, 2017 at 9:21 AM, Jun Lim via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Graham, > > > > Thanks for sharing this. Are you planning on enabling the pass only on > PGO? Even in non-PGO, I noticed some performance gains when we are > aggressive in partially inlining the early return part, especially when the > callee spill CSRs in the entry block. At a high level, I have two > questions: > > 1. What is the main obstacle that prevent the pass from being enabled > by default? > 2. Would it make sense to give some bonus in the cost model when we > detect the possibility of spilling CSRs in the entry block? > > More enhanced shrink-wrapping will probably take care of this, so usingpartial inlining to do that seems like a wrong motivation :) David> > 1. > > > > Thanks, > > Jun > > *From:* Graham Yiu [mailto:gyiu at ca.ibm.com] > *Sent:* Tuesday, October 3, 2017 11:08 AM > *To:* junbuml at codeaurora.org > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] General question about enabling partial inlining > > > > Hi Jun, > > We're actually looking at enhancing the partial inlining pass right now > (see http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html) > > We'd be interested in turning on the pass by default some time in the > future, if our enhancements prove beneficial. > > Cheers, > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: (905) 413-4077 C2-707/8200/Markham > Email: gyiu at ca.ibm.com > > [image: Inactive hide details for via llvm-dev ---09/13/2017 01:12:02 > PM---Hi, I noticed some performance gains in some spec benchmarks]via > llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains > in some spec benchmarks without > > From: via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Date: 09/13/2017 01:12 PM > Subject: [llvm-dev] General question about enabling partial inlining > Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org> > ------------------------------ > > > > > Hi, > > I noticed some performance gains in some spec benchmarks without > significant code size bloat when aggressively performing partial > inlining, especially when the original callee spill CSRs in the entry > block. I guess the partial inlining is not enabled mainly due to the > code size. Is there any other issue which prevent the pass from being > enabled? Do we have any plan or any on-going works to enable partial > inlining ? > Thanks, > Jun > > -- > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a > Linux Foundation Collaborative Project. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists. > llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ& > c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI- > GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_ > dyvEkyCdonAVo&e> > > > > _______________________________________________ > 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/20171003/f0436f94/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/f0436f94/attachment.gif>
Xinliang David Li via llvm-dev
2017-Oct-03 19:46 UTC
[llvm-dev] General question about enabling partial inlining
On Tue, Oct 3, 2017 at 9:45 AM, Graham Yiu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Jun, > > If we were to enable this by default, I think we'd make a push to enable > it with or without PGO. I'm not sure what's currently preventing the > partial inlining pass to be enabled by default, actually. David Li may have > a better sense on this as he's been actively working on it most recently. >Longer term, the partial-inliner should really be just a 'function outlining pass' that serves as an enabler for more aggressive inlining. That of course can be enabled by default (assuming good cost model/heuristics) before the regular inliner. David> > > As for the cost model, right now it's platform independent, so I'm > assuming you'll need some sort of hook for platform-specific costs/bonuses > to detect spilling of different types of registers. Also, I'm not quite > sure how you'll do this type of detection at the IR level. Are you thinking > some sort of heuristic? > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: (905) 413-4077 C2-707/8200/Markham > Email: gyiu at ca.ibm.com > > [image: Inactive hide details for "Jun Lim" ---10/03/2017 12:21:38 PM---Hi > Graham,]"Jun Lim" ---10/03/2017 12:21:38 PM---Hi Graham, > > From: "Jun Lim" <junbuml at codeaurora.org> > To: "'Graham Yiu'" <gyiu at ca.ibm.com> > Cc: <llvm-dev at lists.llvm.org> > Date: 10/03/2017 12:21 PM > Subject: RE: [llvm-dev] General question about enabling partial inlining > ------------------------------ > > > > Hi Graham, > > Thanks for sharing this. Are you planning on enabling the pass only on > PGO? Even in non-PGO, I noticed some performance gains when we are > aggressive in partially inlining the early return part, especially when the > callee spill CSRs in the entry block. At a high level, I have two > questions: > 1. What is the main obstacle that prevent the pass from being enabled by > default? > 2. Would it make sense to give some bonus in the cost model when we > detect the possibility of spilling CSRs in the entry block? > > Thanks, > Jun > *From:* Graham Yiu [mailto:gyiu at ca.ibm.com <gyiu at ca.ibm.com>] > *Sent:* Tuesday, October 3, 2017 11:08 AM > *To:* junbuml at codeaurora.org > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] General question about enabling partial inlining > > Hi Jun, > > We're actually looking at enhancing the partial inlining pass right now > (see *http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2017-2DAugust_116515.html&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=9oYOvB3l33-euX7ag6texitDSABCTLWfauz0YGW7zZ8&s=lZOJDeoavpuEHo29CLd9Kvkn1ibSdgK5125f13O-LYQ&e=> > ) > > We'd be interested in turning on the pass by default some time in the > future, if our enhancements prove beneficial. > > Cheers, > > Graham Yiu > LLVM Compiler Development > IBM Toronto Software Lab > Office: (905) 413-4077 C2-707/8200/Markham > Email: *gyiu at ca.ibm.com* <gyiu at ca.ibm.com> > > [image: Inactive hide details for via llvm-dev ---09/13/2017 01:12:02 > PM---Hi, I noticed some performance gains in some spec benchmarks]via > llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains > in some spec benchmarks without > > From: via llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> > To: *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> > Date: 09/13/2017 01:12 PM > Subject: [llvm-dev] General question about enabling partial inlining > Sent by: "llvm-dev" <*llvm-dev-bounces at lists.llvm.org* > <llvm-dev-bounces at lists.llvm.org>> > ------------------------------ > > > > > Hi, > > I noticed some performance gains in some spec benchmarks without > significant code size bloat when aggressively performing partial > inlining, especially when the original callee spill CSRs in the entry > block. I guess the partial inlining is not enabled mainly due to the > code size. Is there any other issue which prevent the pass from being > enabled? Do we have any plan or any on-going works to enable partial > inlining ? > Thanks, > Jun > > -- > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a > Linux Foundation Collaborative Project. > _______________________________________________ > LLVM Developers mailing list > *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org> > > *https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo&e=* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo&e=> > > > > > > > _______________________________________________ > 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/20171003/23c3b870/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/23c3b870/attachment.gif>
Jun Lim via llvm-dev
2017-Oct-03 19:56 UTC
[llvm-dev] General question about enabling partial inlining
From: Xinliang David Li [mailto:xinliangli at gmail.com] Sent: Tuesday, October 3, 2017 3:22 PM To: Jun Lim <junbuml at codeaurora.org> Cc: Graham Yiu <gyiu at ca.ibm.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] General question about enabling partial inlining On Tue, Oct 3, 2017 at 9:21 AM, Jun Lim via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2. Would it make sense to give some bonus in the cost model when we detect the possibility of spilling CSRs in the entry block? More enhanced shrink-wrapping will probably take care of this, so using partial inlining to do that seems like a wrong motivation :) In some cases, shrink-wrapping cannot shrink and we need to spill in the entry block. In such case partial inlining might help avoiding the execution of spilling CSRs. For example, I also saw 10% improvement in spec2006/astar when we completely avoid executing CSR spills in the entry block using partial inlining. However, as far as I know, the enhanced shrink-wrapping will help more partial shrinking wrapping. David 1. Thanks, Jun From: Graham Yiu [mailto:gyiu at ca.ibm.com <mailto:gyiu at ca.ibm.com> ] Sent: Tuesday, October 3, 2017 11:08 AM To: junbuml at codeaurora.org <mailto:junbuml at codeaurora.org> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] General question about enabling partial inlining Hi Jun, We're actually looking at enhancing the partial inlining pass right now (see <http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116515.html) We'd be interested in turning on the pass by default some time in the future, if our enhancements prove beneficial. Cheers, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 <tel:(905)%20413-4077> C2-707/8200/Markham Email: gyiu at ca.ibm.com <mailto:gyiu at ca.ibm.com> via llvm-dev ---09/13/2017 01:12:02 PM---Hi, I noticed some performance gains in some spec benchmarks without From: via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Date: 09/13/2017 01:12 PM Subject: [llvm-dev] General question about enabling partial inlining Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org> > _____ Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works to enable partial inlining ? Thanks, Jun -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo&e=> &d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=zEValqMYe9FvZqI-GQUgWPmVUgbEq8OBAjTrBjz9xhY&s=1h4Cw3vDlJBIknkn0Ts3R_e3PU64h_dyvEkyCdonAVo&e= _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto: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/20171003/da3a23b8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/da3a23b8/attachment.gif>