llvm dev - May 2015 - [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
<cristiannomartins at hotmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150505/04fae3b8/attachment.html>

Dear Cristianno,

Have you verified that some other pass is not adding the function 
declarations back in after your pass is executed (e.g., by using the 
-debug-pass=Executions argument to see what passes run after your pass)?

Also, does your doFinalization() method make other changes that are 
persistent?

Regards,

John Criswell

On 5/5/15 8:19 PM, Cristianno Martins wrote:
> 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>
>
>
> _______________________________________________
> 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/41f22699/attachment.html>

Hello Cristiano,

I don’t think doFinalization() is really meant to be used this way.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/b6395e3a/attachment.html>

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>