[llvm-dev] function call replacement

[Pierre Gagelin via llvm-dev]

You might be invalidating the iterator after inserting the first CallInst.
There are multiple ways to solve this problem:

>
>
>    1. Make your pass derive from the InstVistor class and implement a
>    visitCallInst() method.  I believe the iterators in the InstVistor class do
>    not get invalidated when new instructions are added.
>    2. Iterate over all the instructions first and record the ones to
>    replace in a container (e.g., a std::vector<>).  A second loop iterates
>    over the container and replaces all the CallInsts stored therein.
>    3. Look up the iterator invalidation rules for the instruction
>    iterator and use the iterator in a way that does not invalidate the
>    iterator.
>
> Good call, method 2. is working fine. I remember seeing such pattern in
BoudsChecking code. I guess I am not the first having troubles with this.

I took a quick look at the iterator problem
 - For the cloned instruction, the problem is it has no parents and I guess
it implies it has no link with previous or next instructions. So some
nullpointers will appear when inserting the instruction because it will try
to build the double linked list of instructions (I think that's the
algorithmic structure employed).
  - For the regular iterator the problem might be just the same. As it is a
double linked list, when you replace the current instruction with another
the current instruction probably is erased. I already made the changes so I
won't try to generate the error again but I thinks that makes sense.

>
>
>
> Regards,
>
> John Criswell
>
> Thanks a lot! About the lli error it appears to have an undefined
behavior. Some times it runs correctly, most of the times it freezes and
sometimes I get the lli error. Anyway, the fact the error says that the
double-linked list is corrupted make sense with my thoughts about the
iterator issue.

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