<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:x="urn:schemas-microsoft-com:office:excel" 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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi guys,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks for showing interest in the performance regression in the LiveIntervals pass that I reported to llvm-dev two weeks ago. Here is again the summary of the post:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">------------<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Some time ago we reported a compile-time performance regression in the LiveIntervals analysis pass (see
<a href="http://llvm.org/bugs/show_bug.cgi?id=18580">http://llvm.org/bugs/show_bug.cgi?id=18580</a>). We detected it at first after migrating from LLVM 3.1 to 3.3, but the problem persists also in 3.5. This regression is especially critical when compiling long
functions. In one of our benchmarks compile time goes from 200s (in 3.1) up to 1500s (in 3.3). Our analysis had shown that the most of time is taken for generation of live intervals for physical registers. In the biggest example, the live interval of one of
the physical registers consists of about 500.000 live ranges. Insertions in the middle of the array of live ranges cause quadratic algorithmic complexity, which is apparently the main reason for the slow-down. I changed the implementation of computeRegUnitInterval()
so that it uses a set instead of the array, and in this way managed to reduce the execution time of the computeRegUnitInterval from 1200s down to about 1s. The fix is a bit ugly, however, because I cannot completely switch to the set, since further analyses
are more efficient on the array. For that reason, I flush the contents of the set into the array at the end of computeRegUnitInterval. I also had to rewrite various operations on the live interval so that they use the set structure if it is available and the
array otherwise.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">-------------<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Last week I took some time to port the patch to llvm-trunk (see the attachment):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- The patch introduces an additional std::set<Segment>* member in LiveRange for storing segments in the phase of initial creation. The set is used if this member is not NULL, otherwise everything works the old way.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- The set of operations on LiveRange used during initial creation (i.e. used by createDeadDefs and extendToUses) have been reimplemented to use the segment set if it is available.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- After a live range is created the contents of the set are flushed to the segment vector, because my experiments had shown that the set is not as efficient as the vector for the later uses of the live range. After the
flushing, the set is deleted and cannot be used again.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- I activated the set only for live ranges computed in LiveIntervalAnalysis::computeLiveInRegUnits() and getRegUnit() but not in computeVirtRegs(), because in the examples that I tested, I could not measure any speed-up
in computeVirtRegs(), and in some cases it got even slower.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I would appreciate if you could take a look at the patch and say what you think about it.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Vaidas<o:p></o:p></span></p>
</div>
</body>
</html>