[LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

Daniel Berlin dberlin at dberlin.org
Mon Feb 23 23:07:16 PST 2015


On Mon, Feb 23, 2015 at 10:51 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> Is it fair (and correct) to say that the main issue with unreachable
> code is this:  if we allow unreachable code then the dom tree is no
> longer a tree, it can have components (disconnected from the root)
> that are cycles.  So no pass that wants to just work with unreachable
> code can depend on the dom tree actually being a tree.
>
> Or are there more fundamental issues (I realize the dom tree not being
> a tree is rather fundamental itself)?
>

You can't rely on walking successors to generate correct code (IE you may
have to later fix up code that you didn't see).
You can't rely on basic blocks you look at actually having otherwise-valid
code.
You can't rely on phi nodes having predecessors that are valid (IE if you
walk up the graph, you can validly hit invalid code).
etc

Essentially, you have *no guarantee*, at all, what is in an unreachable
block.

You get instructions like this from jump threading:

  %2 = getelementptr inbounds i8* %2, i64 1


It's not clear what one is supposed to do with such an instruction, and in
fact, a lot of the existing passes (beside GVN) will enter an infinite loop
if you convince them to look at it.


It seems quite bad to say "well, you know, everywhere else you have
well-formed code. But if you hit an unreachable block (and PS, you'll have
to check yourself to see if you are in one of these magic blocks all of the
sudden), all bets are off, and you should be prepared to hit anything".




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


More information about the llvm-dev mailing list