<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=utf-8">
<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;}
@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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
.MsoPapDefault
{mso-style-type:export-only;
line-height:115%;}
@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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<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""> Cristianno Martins [mailto:cristiannomartins@gmail.com]
<br>
<b>Sent:</b> Thursday, May 07, 2015 21:10<br>
<b>To:</b> Kuperstein, Michael M<br>
<b>Cc:</b> John Criswell; Lista LLVM-dev<br>
<b>Subject:</b> Re: [LLVMdev] (Possibly buggy?) doFinalization method behavior of FunctionPass<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">Well, to be fair, the main idea of having FunctionPasses in the first place is that (please, correct me if I'm mistaken) opt could be running different passes on different functions at the same
time, so the compilation process could be sped up. I know the parallel part of this is not yet implemented on LLVM, but I think I can assume that my pass is going to work on a function, and other passes will work over the same function after mine, even before
my pass can start again its work over the next function. In a way, doesn't it mean that my pass keeps "half-baking" its work one function at a time until it finishes all of them for a given module?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">As long as the pass’s modifications for each function don’t depend on modifications made to another function, that
function is “fully-baked”. :-)<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">And if these modifications do depend on what you do to another function, then I’d suggest the pass should be a ModulePass.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">This is actually why I think doFinalization should have a different perspective between Module and "TheRestOfThe"-Passes: given that a module is the basic unit of compilation for opt, doFinalization
is going to be called as many times as runOnModule for every module you try to transform/analyze on a ModulePass. This is not true for FunctionPass, for example: if I have to do some work only once, and preferably after finishing with all functions, I would
have to insert some if clause into my runOnFunction that checks a counter of functions and would effectively run only if I already ran NumberOfFunctionsWithoutConsideringDefinitions times -- which is hardly a good programming method. Besides, if what I assumed
above is really true (that there is no guarantee that your FunctionPass finishes with the module before other FunctionPasses run over some of the functions), even this strategy is worthless: the code could be changed by other passes between the first and last
execution of my pass runOnFunction =/<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">That’s exactly my point – if you have to do some work only once, and that work has module-wide impact (as opposed
to function-wide), then I believe you ought to be using a ModulePass. Yes, this imposes a constraint on scheduling that’s probably stronger than you want, but I don’t think there’s a way to express “run my pass over functions in parallel (in theory), then
run another part of it over the module, but make sure nothing bad happens in between”.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">a. AsmPrinter: a MachineFunctionPass who's doFinalization is defined at line 1004 of lib/CodeGen/AsmPrinter.cpp<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">b. Inliner: a CallGraphSCCPass, having doFinalization defined at lib/Transforms/IPO/Inliner.cpp:621<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">c. BBPassManager: a FunctionPass, at lib/IR/LegacyPassManager.cpp:1344<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">d. FunctionPassManager: a Pass, at lib/IR/LegacyPassManager.cpp:1441<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">(a) is not an IR-to-IR pass. It only reads the module to generate output, it doesn’t actually write to the module.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">(c) and (d) are part of the PassManager infrastructure, and can make assumptions about ordering that a regular pass
shouldn’t. And, in any case, the only thing they seem to do with the module/function they get is to pass it on to the doFinalization() methods of their contained passes.<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">(b) seems to be the only real example of this in-tree, and it’s insanely old code by LLVM standards (written by Chris
in 2004). So, perhaps, originally this is the way it was meant to work. But I’m fairly certain this is not a preferred practice today.
<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D">Again, I’d really appreciate it if anyone with more in-depth knowledge of the infrastructure could comment.
<o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt;line-height:115%">On the other hand, assuming the documentation is actually wrong, and doFinalization shouldn't be allowed to change the module, I still couldn't see why exactly doFinalization functions have a
Module& as argument (at least the FunctionPass one), or a boolean return type for that matter; in other words, I would guess the signature of this function is wrongly defined anyways.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%">cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><br>
--<br>
Cristianno Martins<br>
PhD Student of Computer Science<br>
University of Campinas<br>
<a href="mailto:cmartins@ic.unicamp.br" target="_blank">cmartins@ic.unicamp.br</a><o:p></o:p></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>