<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:11pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Eric,</p>
<p><br>
</p>
<p>Thank you for feedback. <span>I must apologise if I have caused any concern or offence.</span></p>
<p><span><br>
</span></p>
<p><span>-Evgeny</span></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Eric Christopher <echristo@gmail.com><br>
<b>Sent:</b> Monday, July 31, 2017 5:57:01 PM<br>
<b>To:</b> Evgeny Astigeevich; River Riddle; Chris Bieneman<br>
<b>Cc:</b> llvm-dev; nd<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Add IR level interprocedural outliner for code size.</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Evgeny,<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Jul 31, 2017 at 8:47 AM Evgeny Astigeevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Chris,<u></u><u></u></span></p>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#454545">> One particular disagreement that I think very much needs to be revisited in this thread was Jessica's proposal of a pipeline of:<u></u><u></u></span></p>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="color:#454545">> 1. IR outline<u></u><u></u></span></p>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="color:#454545">> 2. Inline<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#454545">> 3. MIR outline<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">IMHO, there is no need to restrict a place of the Outliner in the pipeline at the moment. I hope people representing different architectures will try different
configurations and the best will be chosen. I’d like to try the pipeline configuration:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is largely irrelevant to the discussion at hand. The original thoughts were about one or the other and Jessica has rightly pointed out (which you seem to agree with) that there's room for both in the pipeline.</div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>-eric</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u></span></p>
<p class="m_-4189602985864275422MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Inline<u></u><u></u></span></p>
<p class="m_-4189602985864275422MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">IR optimizations<u></u><u></u></span></p>
<p class="m_-4189602985864275422MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">IR outline<u></u><u></u></span></p>
<p class="m_-4189602985864275422MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">MIR optimizations<u></u><u></u></span></p>
<p class="m_-4189602985864275422MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">MIR outline<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this configuration allows to apply as many IR optimizations, especially those which reduce code size, as possible and then extract commonly used code
into functions. I am also interested in some kind of Oz LTO with the IR Outliner enabled.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="m_-4189602985864275422MsoPlainText">Evgeny Astigeevich<u></u><u></u></p>
<p class="m_-4189602985864275422MsoPlainText">Senior Compiler Engineer<u></u><u></u></p>
<p class="m_-4189602985864275422MsoPlainText">Compilation Tools<u></u><u></u></p>
<p class="m_-4189602985864275422MsoPlainText">ARM<u></u><u></u></p>
<p class="m_-4189602985864275422MsoPlainText"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>River Riddle via llvm-dev<br>
<b>Sent:</b> Saturday, July 29, 2017 6:33 AM<br>
<b>To:</b> Chris Bieneman<br>
<b>Cc:</b> llvm-dev</span></p>
</div>
</div>
</div>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Add IR level interprocedural outliner for code size.<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi Chris,<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4189602985864275422WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It's okay to put this on the spot because posting the patches was meant to help further the discussion that kind of stalled previously. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">On Fri, Jul 28, 2017 at 9:58 PM, Chris Bieneman <<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="color:#454545">Apologies for delayed joining of this discussion, but I had a few notes from this thread that I really wanted to chime in about.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">River,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">I don't mean to put you on the spot, but I do want to start on a semantic issue. In several places in the thread you used the words "we" and "our" to imply that you're not alone in writing this (which is totally
fine), but your initial thread presented this as entirely your own work. So, when you said things like "we feel there's an advantage to being at the IR level", can you please clarify who is "we"?<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"> In regards to the words "we" and "our", I am referring to myself. My writing style tends to shift between the usage of those words. I'll avoid any kind of confusion in the future. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Given that there are a number of disagreements and opinions floating around I think it benefits us all to speak clearly about who is taking what stances.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">One particular disagreement that I think very much needs to be revisited in this thread was Jessica's proposal of a pipeline of:<u></u><u></u></span></p>
</div>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoNormal" style="color:#454545">IR outline<u></u><u></u></li><li class="MsoNormal" style="color:#454545">Inline<u></u><u></u></li><li class="MsoNormal" style="color:#454545">MIR outline<u></u><u></u></li></ol>
<div>
<p class="MsoNormal"><span style="color:#454545">In your response to that proposal you dismissed it out of hand with "feelings" but not data. Given that the proposal came from Jessica (a community member with significant relevant experience in outlining), and
it was also recognized as interesting by Eric Christopher (a long-time member of the community with wide reaching expertise), I think dismissing it may have been a little premature.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I dismissed the idea of an outliner at the machine level being able to catch bad inlining decisions. Given the loss of information between the two I felt it was a little optimistic to rely on a very late pass being able to reverse those
decisions, especially coupled with the fact that the current machine outliner requires exact equivalence. I don't disagree with the proposal of an example : outline, inline, outline: pipeline, but the idea of being able to catch inlining decisions given the
circumstances seemed optimistic to me. From there I went ahead and implemented a generic interface for outlining that can be shared between IR/Machine level so that such a pipeline could be more feasible.<br>
<span style="color:#1f497d"><u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">I also want to visit a few procedural notes.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Mehdi commented on the thread that it wouldn't be fair to ask for a comparative study because the MIR outliner didn't have one. While I don't think anyone is asking for a comparative study, I want to point out
that I think it is completely fair. If a new contributor approached the community with a new SROA pass and wanted to land it in-tree it would be appropriate to ask for a comparative analysis against the existing pass. How is this different? <u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The real question comes from what exactly you want to define as a "comparative analysis". When posting the patch I included additional performance data( found here <a href="http://goo.gl/5k6wsP" target="_blank">goo.gl/5k6wsP</a>) that includes
benchmarking and comparisons between the outliner that I am proposing and the machine outliner on a wide variety of benchmarks. The proposed outliner performs quite favorable in comparison. As for feature comparison, the proposed outliner has many features
currently missing from the machine outliner: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - parameterization<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - outputs<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - relaxed equivalence(machine outliner requires exact)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - usage of profile data<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - support for opt remarks<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> The machine outliner currently only supports X86 and AArch64, the IR outliner can/should support all targets immediately without the requirement of ABI restrictions(mno-red-zone is required for the machine outliner).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> At the IR level we have much more opportunity to find congruent instructions than at the machine level given the possible variation at that level: RA, instruction selection, instruction scheduling, etc.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I am more than willing to do a comparative analysis but I'm not quite sure what the expectation for one is.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Adding a new IR outliner is a different situation from when the MIR one was added. When the MIR outliner was introduced there was no in-tree analog. When someone comes to the community with something that has
no existing in-tree analog it isn't fair to necessarily ask them to implement it multiple different ways to prove their solution is the best. However, as a community, we do still exercise the right to reject contributions we disagree with, and we frequently
request changes to the implementation (as is shown every time someone tries to add SPIR-V support).<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I perfectly agree :) <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#454545">In the LLVM community we have a long history of approaching large contributions (especially ones from new contributors) with scrutiny and discussion. It would be a disservice to the project to forget that.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">River, as a last note. I see that you've started uploading patches to Phabricator, and I know you're relatively new to the community. When uploading patches it helps to include appropriate reviewers so that the
right people see the patches as they come in. To that end can you please include Jessica as a reviewer? Given her relevant domain experience I think her feedback on the patches will be very valuable.<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I accidentally posted without any reviewers at first, I've been going back through and adding people I missed. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Thank you,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">-Chris<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">I appreciate the feedback and welcome all critical discussion about the right way to move forward.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> River Riddle<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue","serif";color:#454545"><u></u> <u></u></span></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jul 26, 2017, at 1:52 PM, River Riddle via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Hey Sanjoy,<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">On Wed, Jul 26, 2017 at 1:41 PM, Sanjoy Das via llvm-dev<span class="m_-4189602985864275422gmail-m6024304041736294512apple-converted-space"> </span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><span class="m_-4189602985864275422gmail-m6024304041736294512apple-converted-space"> </span>wrote:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Hi,<br>
<br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">On Wed, Jul 26, 2017 at 12:54 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> The way I interpret Quentin's statement is something like:</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">></span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> - Inlining turns an interprocedural problem into an intraprocedural problem</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> - Outlining turns an intraprocedural problem into an interprocedural problem</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">></span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> Insofar as our intraprocedural analyses and transformations are strictly</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> more powerful than interprocedural, then there is a precise sense in which</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> inlining exposes optimization opportunities while outlining does not.</span><br>
<br>
While I think our intra-proc optimizations are *generally* more<br>
powerful, I don't think they are *always* more powerful. For<br>
instance, LICM (today) won't hoist full regions but it can hoist<br>
single function calls. If we can extract out a region into a<br>
readnone+nounwind function call then LICM will hoist it to the<br>
preheader if the safety checks pass.<br>
<br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> Actually, for his internship last summer River wrote a profile-guided</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> outliner / partial inliner (it didn't try to do deduplication; so it was</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> more like PartialInliner.cpp). IIRC he found that LLVM's interprocedural</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> analyses were so bad that there were pretty adverse effects from many of the</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> outlining decisions. E.g. if you outline from the left side of a diamond,</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> that side basically becomes a black box to most LLVM analyses and forces</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> downstream dataflow meet points to give an overly conservative result, even</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> though our standard intraprocedural analyses would have happily dug through</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> the left side of the diamond if the code had not been outlined.</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">></span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> Also, River's patch (the one in this thread) does parameterized outlining.</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> For example, two sequences containing stores can be outlined even if the</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> corresponding stores have different pointers. The pointer to be loaded from</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> is passed as a parameter to the outlined function. In that sense, the</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> outlined function's behavior becomes a conservative approximation of both</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> which in principle loses precision.</span><br>
<br>
Can we outline only once we've already done all of these optimizations<br>
that outlining would block?<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> The outliner is able to run at any point in the interprocedural pipeline. There are currently two locations: Early outlining(pre inliner) and late outlining(practically
the last pass to run). It is configured to run either Early+Late, or just Late. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><u></u> <u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> I like your EarlyCSE example and it is interesting that combined with</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> functionattrs it can make a "cheap" pass get a transformation that an</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> "expensive" pass would otherwise be needed. Are there any cases where we</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> only have the "cheap" pass and thus the outlining would be essential for our</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> optimization pipeline to get the optimization right?</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">></span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> The case that comes to mind for me is cases where we have some cutoff of</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> search depth. Reducing a sequence to a single call (+ functionattr</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> inference) can essentially summarize the sequence and effectively increase</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> search depth, which might give more results. That seems like a bit of a weak</span><br>
<span class="m_-4189602985864275422gmail-m6024304041736294512gmail-">> example though.</span><br>
<br>
I don't know if River's patch outlines entire control flow regions at<br>
a time, but if it does then we could use cheap basic block scanning<br>
analyses for things that would normally require CFG-level analysis.<u></u><u></u></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> The current patch currently just supports outlining from within a single block. Although, I had a working prototype for Region based outlining, I kept it from this patch
for simplicity. So its entirely possible to add that kind of functionality because I've already tried.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">Thanks,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> River Riddle<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""> <u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
-- Sanjoy<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
><br>
> -- Sean Silva<br>
><br>
> On Wed, Jul 26, 2017 at 12:07 PM, Sanjoy Das via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Wed, Jul 26, 2017 at 10:10 AM, Quentin Colombet via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> > No, I mean in terms of enabling other optimizations in the pipeline like<br>
>> > vectorizer. Outliner does not expose any of that.<br>
>><br>
>> I have not made a lot of effort to understand the full discussion here (so<br>
>> what<br>
>> I say below may be off-base), but I think there are some cases where<br>
>> outlining<br>
>> (especially working with function-attrs) can make optimization easier.<br>
>><br>
>> It can help transforms that duplicate code (like loop unrolling and<br>
>> inlining) be<br>
>> more profitable -- I'm thinking of cases where unrolling/inlining would<br>
>> have to<br>
>> duplicate a lot of code, but after outlining would require duplicating<br>
>> only a<br>
>> few call instructions.<br>
>><br>
>><br>
>> It can help EarlyCSE do things that require GVN today:<br>
>><br>
>> void foo() {<br>
>> ... complex computation that computes func()<br>
>> ... complex computation that computes func()<br>
>> }<br>
>><br>
>> outlining=><br>
>><br>
>> int func() { ... }<br>
>><br>
>> void foo() {<br>
>> int x = func();<br>
>> int y = func();<br>
>> }<br>
>><br>
>> functionattrs=><br>
>><br>
>> int func() readonly { ... }<br>
>><br>
>> void foo(int a, int b) {<br>
>> int x = func();<br>
>> int y = func();<br>
>> }<br>
>><br>
>> earlycse=><br>
>><br>
>> int func(int t) readnone { ... }<br>
>><br>
>> void foo(int a, int b) {<br>
>> int x = func(a);<br>
>> int y = x;<br>
>> }<br>
>><br>
>> GVN will catch this, but EarlyCSE is (at least supposed to be!) cheaper.<br>
>><br>
>><br>
>> Once we have an analysis that can prove that certain functions can't trap,<br>
>> outlining can allow LICM etc. to speculate entire outlined regions out of<br>
>> loops.<br>
>><br>
>><br>
>> Generally, I think outlining exposes information that certain regions of<br>
>> the<br>
>> program are doing identical things. We should expect to get some mileage<br>
>> out of<br>
>> this information.<br>
>><br>
>> -- Sanjoy<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>><span class="m_-4189602985864275422gmail-m6024304041736294512apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>><span class="m_-4189602985864275422gmail-m6024304041736294512apple-converted-space"> </span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></span></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">_______________________________________________<br>
LLVM Developers mailing list<br>
</span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">llvm-dev@lists.llvm.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif""><br>
</span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>