[LLVMdev] questions about delete instructions

Reid Spencer reid at x10sys.com
Sun May 22 22:27:02 PDT 2005


Welcome, Shuhan,

LLVM is trying to help you here. In generally, most of the tools will
run a verification pass on the module you're constructing or editing.
There are numerous tests that it checks and it will abort with one of
those messages if anything breaks an inviolable rule. You've managed to
break two of them :)

1. "use stuck around after a def is destroyed". 

This is basically a dangling pointer problem. You have a reference to
something that has been deleted. Typically this means you did something
like:

Instruction *i = ...
i->eraseFromParent();

What you need to do is also call i->replaceAllUsesWith(someValue).
Either that or manually ensure that all places that use "i" are updated
to use something else before you erase i.

2. "def must dominate all the use"

Remember that this is SSA (Static Single Assignment). A value can only
be assigned once. And hence that value is said to dominate all its uses.
You've somehow managed to arrange the code to violate this principle.
This could also be a side effect of problem 1, but its more likely a
fact of simply copying the instruction to another block.

Hope this helps.

Reid 


On Sun, 2005-05-22 at 22:41 -0400, shding at mtu.edu wrote:
>     I'm a new guy for llvm. I'm doing a project in which some instructions
>  should be moved from one block into another. Those instructions may
> be data-dependent. When I tried to delete them one by one, it cause
> the error message like, " use stuck around after a def is destroyed"
> even if I deleted the use befor the def. When I tried to add them to
> another block, errors occurred like "def must dominate all the use".
>     Could anybody help me with that? Thank!
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050522/733a39b2/attachment.sig>


More information about the llvm-dev mailing list