<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 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hello Jordan and Ted,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Is it the right time now to look again at unifying the two DataflowWorklists?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Last month, we’ve got as far as establishing that the DataflowWorklist in UninitializedValues may not have been intended to start with all blocks implicitly enqueued, since it gets some blocks enqueued onto it explicitly right after the creation; but we couldn’t decide without Ted whether the difference in implementation of the two DataflowWorklists was intentional or not.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jordan Rose [<a href="mailto:jordan_rose@apple.com">mailto:jordan_rose@apple.com</a>] <br><b>Sent:</b> 28 April 2014 17:30<br><b>To:</b> Artyom Skrobov<br><b>Cc:</b> Ted Kremenek; <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br><b>Subject:</b> Re: [PATCH] Factor DataflowWorklist out of LiveVariables and UninitializedValues analyses<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Apr 25, 2014, at 10:43 , Artyom Skrobov <<a href="mailto:Artyom.Skrobov@arm.com">Artyom.Skrobov@arm.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal><span style='color:#1F497D'>><span class=apple-converted-space> </span></span>Are you sure this is correct? One worklist treats the entry block as already analyzed, the other doesn't. One starts with no blocks enqueued, the other effectively has<span class=apple-converted-space> </span><i>all</i> blocks enqueued because of the iterators.<o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Well, the patch keeps all tests passing.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>How can we trigger the supposed difference in their behaviour?</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anyway, the version that “effectively has<span class=apple-converted-space> </span><i>all</i> blocks enqueued because of the iterators” had</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Courier New";color:#1F497D'> worklist.enqueueSuccessors(&cfg.getEntry());</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>called immediately upon the creation.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What would be the point of enqueuing blocks onto a list that already has all blocks enqueued?</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Well, it could have resulted in traversal in a different order, but it doesn't. I'm not sure that entry actually does <i>anything</i>, since all blocks will be enqueued at the time. I wonder if this means we're using a less efficient traversal order than Ted intended...it wouldn't be the first time we've updated the same code multiple times and accidentally broken the algorithm. :-(<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I guess I'm not comfortable applying this until we know what the intended traversal is for each analysis. Unfortunately Ted (being a manager) probably will not have time to look at this until after WWDC, i.e. another month from now.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='color:#1F497D'>></span> Why doesn't enqueueSuccessors use enqueueBlock?<o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for spotting that! Attaching the updated patch.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='color:#1F497D'>></span><span class=apple-converted-space> </span>Since this is only used by classes in the same component of Clang, it might make sense to put even the header in the lib/ directory. That way it doesn't show up when other people build tools on top of Clang. Then again, it is a generally reusable component.<o:p></o:p></p></div></div><div><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes, I think it is as generally reusable as PostOrderCFGView it builds upon (which is, similarly, only used by classes in the same component).</span><o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Fair enough.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Jordan<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>