<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Arial",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Hello,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">I am exploring the possibility of unifying the BC file generation phase for ThinLTO and FullLTO. Our third party library providers prefer to give us only one version
of the BC archives, rather than test and ship both Thin and Full LTO BC archives. We want to find a way to allow our users to pick either Thin or Full LTO, while having only one “unified” version of the BC archive.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Note, I am not necessarily proposing to do this work in the upstream compiler. If there is no interest from other companies, we might have to keep this as a private
patch for Sony.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">One of the ideas (not my preference) is to mix and match files in the Thin and Full BC formats. I'm not sure how well the "mix and match" scenario works in general.
I was wondering if Apple or Google are doing this for production?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">I wrote a toy example, compiled one group of files with ThinLTO and the rest with FullLTO, linked them with gold. I saw that irrespective of whether the Thin or Full
LTO option was used at the link step, files are optimized within the Thin group and within the Full group separately, but they don't know about the files in the other group (which makes sense). Basically, the border between Thin and Full LTO bitcode files
created an artificial "barrier" which prevented cross-border optimization.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Obviously, I am not too fond of this idea. Even if mixing and matching ThinLTO and FullLTO bitcode files will work “as is”, I suspect we will see a non-trivial runtime
performance degradation because of the "ThinLTO"/"FullLTO" border. Are you aware of any potential problems with this solution, other than performance?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Another, hopefully, better idea is to introduce a "unified" BC format, which could either be FullLTO, ThinLTO, or neither (e.g., something in between).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">If the user chooses FullLTO at the link step, but some of the files are in the Thin BC format – the linker will call a special LTO API to convert these files to the
Full LTO BC format (i.e., stripping the module summary section + potentially do some additional optimizations from the FullLTO pass manager pipeline).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">If the user chooses ThinLTO at the link step, but some of the files are in the Full BC format – the linker will call an LTO API to convert these files to the Thin LTO
bitcode format (by regenerating the module summary section dynamically for the Full LTO bitcode files).
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">I think the most reasonable idea for the unification of the Thin and Full LTO compilation pipelines is to use Full LTO as the “unified” BC format. If the user requests
FullLTO – no additional work is needed, the linker will perform FullLTO as usual. If the user request ThinLTO, the linker will call an API to regenerate the module summary section for all the files in the FullLTO format and perform ThinLTO as usual.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">In reality I suspect things will be much more complicated. The pipelines for the Thin and Full LTO compilation phases are quite different. ThinLTO can afford to do much
more optimization in the linking phase (since it has parallel backends & smaller IR compared to FullLTO), while for FullLTO we are forced to move some optimizations from linking to the compilation phase.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">So, if we pick FullLTO as our unified format, we would increase the build time for ThinLTO (we will be doing the FullLTO initial optimization pipeline in the compile
phase, which is more than what ThinLTO is currently doing, but the pipeline of the optimizations in the backend will stay the same). It’s not clear what will happen with the runtime performance: we might improve it (because we repeat some of the optimizations
several times), or we might make it worse (because we might do an optimization in the early compilation phase, potentially preventing more aggressive optimization later). What are your expectations? Will this approach work in general? If so, what do you think
will happen with the runtime performance?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">I also noticed that the pass manager pipeline is different for ThinLTO+Sample PGO (use profile case). This might create some additional complications for unification
of Thin and FullLTO BC generation phase too, but it’s too small detail to worry about right now. I’m more interested in choosing a right general direction for solving this problem now.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Please share your thoughts!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Thank you!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="color:black">Katya.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
</div>
</body>
</html>