[LLVMdev] (Possibly buggy?) doFinalization method behavior of FunctionPass

[John Criswell]

On 5/6/15 10:19 AM, Kuperstein, Michael M wrote:
>
> Hello Cristiano,
>
> I don’t think doFinalization() is really meant to be used this way.
>

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)?

If that is not the case, then there is either a bug in the code or a bug 
in the documentation.

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.

Regards,

John Criswell

> Its purpose is to allow clean-up of internal data-structures used by 
> the pass itself, not to make additional changes to the module.
>
> 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.
>
> Michael
>
> *From:*llvmdev-bounces at cs.uiuc.edu 
> [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Cristianno Martins
> *Sent:* Wednesday, May 06, 2015 03:20
> *To:* Lista LLVM-dev
> *Subject:* [LLVMdev] (Possibly buggy?) doFinalization method behavior 
> of FunctionPass
>
> Hello there,
>
> 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 =)
>
> 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).
>
> 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.
>
> 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.
>
> 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).
>
> 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?
>
> Thanks in advance,
>
> Oh, and before I forget, this is the version of the opt I'm running:
>
> LLVM (http://llvm.org/):
>
>   LLVM version 3.7.0svn
>
>   DEBUG build with assertions.
>
>   Built May  4 2015 (00:18:21).
>
>   Default target: x86_64-apple-darwin14.3.0
>
>   Host CPU: sandybridge
>
>
> --
> Cristianno Martins
> PhD Student of Computer Science
> University of Campinas
> cmartins at ic.unicamp.br <mailto:cmartins at ic.unicamp.br>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/cbd959cc/attachment.html>