<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 5/6/15 11:15 AM, Kuperstein, Michael
M wrote:<br>
</div>
<blockquote
cite="mid:251BD6D4E6A77E4586B482B33960D2284CB3DC9B@HASMSX106.ger.corp.intel.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<div class="WordSection1">
<p class="MsoNormal"><span>I’ve always thought that the only
guarantee is that doFinalization(Module &M) runs after
runOnFunction() was executed for all functions in M, and
there’s no guarantee it runs *immediately* after. </span></p>
<p class="MsoNormal"><span>That is, a PM may run a bunch of
function passes over each function, and only then call
doFinazliation() for each pass. That means that, even though
you get a mutable reference to the module, the module you’ll
see is quite different from what you may expect.</span></p>
</div>
</blockquote>
<br>
Correct. You're guaranteed that doFinalization() is run after your
pass has been executed over all the functions. There's no
guarantees about what other passes are going to do either before or
after doFinalization() is called.<br>
<br>
Therefore, it's fine for doFinalization() to modify the Module. You
just have to be aware that other passes may change the Module later.
That's why I asked whether there are any other passes executed after
Cristianno's pass: they can (theoretically) add the function
declarations back into the Module.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<blockquote
cite="mid:251BD6D4E6A77E4586B482B33960D2284CB3DC9B@HASMSX106.ger.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>People more familiar with the pass
managers – please correct me if I’m wrong.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Michael</span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span> </span></a></p>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span> John
Criswell [<a class="moz-txt-link-freetext" href="mailto:jtcriswel@gmail.com">mailto:jtcriswel@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, May 06, 2015 17:29<br>
<b>To:</b> Kuperstein, Michael M; Cristianno Martins;
Lista LLVM-dev<br>
<b>Subject:</b> Re: [LLVMdev] (Possibly buggy?)
doFinalization method behavior of FunctionPass</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On 5/6/15 10:19 AM, Kuperstein, Michael M
wrote:</p>
</div>
<blockquote>
<div>
<p class="MsoNormal">Hello Cristiano,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I don’t think doFinalization() is
really meant to be used this way.</p>
</div>
</blockquote>
<p class="MsoNormal"><br>
My understanding is that doInitialization() and
doFinalization() are designed specifically for modifying the
LLVM IR (otherwise, why would a mutable reference to the
Function be provided)?<br>
<br>
If that is not the case, then there is either a bug in the
code or a bug in the documentation.<br>
<br>
That said, I agree with the suggestion of writing a
ModulePass. Since the PassManager does not run FunctionPasses
in parallel yet, there's little benefit to using them. I have
often found the limitations on FunctionPasses to not be worth
the hassle.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<br>
</p>
<div>
<p class="MsoNormal">Its purpose is to allow clean-up of
internal data-structures used by the pass itself, not to
make additional changes to the module.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">One option would be to rewrite your pass
as a ModulePass instead of a FunctionPass, then iterating
over the functions manually, and doing the final clean-up
once that’s done.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Michael</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>From:</b>
<a moz-do-not-send="true"
href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>
[<a moz-do-not-send="true"
href="mailto:llvmdev-bounces@cs.uiuc.edu">mailto:llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Cristianno Martins<br>
<b>Sent:</b> Wednesday, May 06, 2015 03:20<br>
<b>To:</b> Lista LLVM-dev<br>
<b>Subject:</b> [LLVMdev] (Possibly buggy?) doFinalization
method behavior of FunctionPass</p>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Hello there,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I'm writing some LLVM passes, and
just ran into an interesting situation: now, I don't
know if I misunderstood the way doFinalization is
supposed to work, but I hope someone could help =)</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">One of the transformations I wrote
needed to replace some instructions within the code, so
I needed to clean up the code after the process was
completed. The pass basically swapped some function
calls (from the standard C library) with my own
implementation of those functions. Changing the code in
this way, though, creates some dead code (like those
dead prototypes that are not being used anymore).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I, then, implemented the "clean up"
strategy overriding doFinalization. Unfortunately, any
modifications done to the module in this method appears
to be ignored by LLVM. I even dumped the module directly
from within the method, and could see that the
modifications were applied to that reference of the
module, but the .bc file opt wrote into does not retain
these changes.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Now, bear with me here: I know that
other passes like DCE could be used to clean the
bytecode, but some of the code I implemented in
doFinalization actually needed to run only once, and
necessarily after the pass has finished: this is where I
check to see if there is some extra situation I need to
address, optimize some of the replaced instructions, and
verify if any of the functions that I want to remove had
their addresses taken by any instruction.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Also, doFinalization has a bool
return type, but it doesn't appear to have any different
behavior if I return either value =/ (I assumed the
general idea would be "return true if the module was
modified in any way", like runOnFunction, but I couldn't
find anything to support that anywhere).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thus, am I wrong about how to use
doFinalization? If so, is there any way to guarantee
running some code only once and only when a pass already
finished its job?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks in advance,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Oh, and before I forget, this is the
version of the opt I'm running:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">LLVM (<a moz-do-not-send="true"
href="http://llvm.org/">http://llvm.org/</a>):</p>
</div>
<div>
<p class="MsoNormal"> LLVM version 3.7.0svn</p>
</div>
<div>
<p class="MsoNormal"> DEBUG build with assertions.</p>
</div>
<div>
<p class="MsoNormal"> Built May 4 2015 (00:18:21).</p>
</div>
<div>
<p class="MsoNormal"> Default target:
x86_64-apple-darwin14.3.0</p>
</div>
<div>
<p class="MsoNormal"> Host CPU: sandybridge</p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
--<br>
Cristianno Martins<br>
PhD Student of Computer Science<br>
University of Campinas<br>
<a moz-do-not-send="true"
href="mailto:cmartins@ic.unicamp.br"
target="_blank">cmartins@ic.unicamp.br</a></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>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>_______________________________________________</pre>
<pre>LLVM Developers mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></pre>
<pre><a moz-do-not-send="true" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></pre>
<p class="MsoNormal"><br>
<br>
<br>
</p>
<pre>-- </pre>
<pre>John Criswell</pre>
<pre>Assistant Professor</pre>
<pre>Department of Computer Science, University of Rochester</pre>
<pre><a moz-do-not-send="true" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre>
</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>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre>
</body>
</html>