fix bug in block renaming for dead code elimination

[yhls]

IncrementalCompact can't deal with predecessors referred to by index 0, but according to @Keno, these are virtual and should not be renamed. I've changed IncrementalCompact to leave these predecessors as they are. To do this, I've also made it so that blocks that are to be removed are renamed to -1 rather than 0, to avoid conflicting with 0s that should be kept.

This should address JuliaDebug/Cthulhu.jl#28

[Keno]

LGTM, but could ideally use a test.

[JeffBezanson]

Thanks @yhls, very nice first PR to julialang/julia. Welcome!

[yhls]

Thanks for the welcome!

I'm going travelling after graduation tomorrow until mid-August, but I'll try to tie this PR up in the next week. I've also found a small bug in my PR, which I'll fix very soon.

[yhls]

I've just added a test--how do things look?

[vchuravy]

Thanks! Can you squash and rebase onto master?

[yhls]

Ok, squashed and rebased.

By the way, I've noticed that with these changes, reversing the change in #29265 (so making IncrementalCompact remove dead code by default again) causes the build process to fail when producing corecompiler.ji (see below). Do you have any suspects in mind for why this might be happening?

[yhls julia]% make
    JULIA usr/lib/julia/corecompiler.ji
essentials.jl
ctypes.jl
generator.jl
reflection.jl
options.jl
promotion.jl
tuple.jl
pair.jl
traits.jl
range.jl
expr.jl
error.jl
bool.jl
number.jl
int.jl
operators.jl
pointer.jl
refvalue.jl
indices.jl
array.jl
abstractarray.jl
bitarray.jl
bitset.jl
abstractdict.jl
abstractset.jl
iterators.jl
namedtuple.jl
docs/core.jl
ordering.jl
sort.jl
compiler/utilities.jl
compiler/validation.jl
compiler/inferenceresult.jl
compiler/params.jl
compiler/inferencestate.jl
compiler/typeutils.jl
compiler/typelimits.jl
compiler/typelattice.jl
compiler/tfuncs.jl
compiler/abstractinterpretation.jl
compiler/typeinfer.jl
compiler/optimize.jl
compiler/ssair/driver.jl
compiler/ssair/ir.jl
compiler/ssair/domtree.jl
compiler/ssair/slot2ssa.jl
compiler/ssair/queries.jl
compiler/ssair/passes.jl
compiler/ssair/inlining.jl
compiler/ssair/verify.jl
compiler/ssair/legacy.jl
compiler/bootstrap.jl
error during bootstrap:
LoadError(at "compiler/compiler.jl" line 3: LoadError(at "compiler/bootstrap.jl" line 8: UndefVarError(var=:string)))
rec_backtrace at /home/yhls/julia/src/stackwalk.c:94
jl_throw at /home/yhls/julia/src/task.c:217
jl_undefined_var_error at /home/yhls/julia/src/rtutils.c:130
jl_get_binding_or_error at /home/yhls/julia/src/module.c:288
unknown function (ip: 0x7f22dfa057c7)
unknown function (ip: 0x7f22dfa05b28)
unknown function (ip: 0x7f22dfa05b67)
_jl_invoke at /home/yhls/julia/src/gf.c:2049 [inlined]
jl_apply_generic at /home/yhls/julia/src/gf.c:2213
unknown function (ip: 0x7f22dfc2fe5d)
_jl_invoke at /home/yhls/julia/src/gf.c:2049 [inlined]
jl_apply_generic at /home/yhls/julia/src/gf.c:2213
unknown function (ip: 0x7f22dfc2a2aa)
_jl_invoke at /home/yhls/julia/src/gf.c:2049 [inlined]
jl_apply_generic at /home/yhls/julia/src/gf.c:2213
unknown function (ip: 0x7f22dfba1230)
_jl_invoke at /home/yhls/julia/src/gf.c:2049 [inlined]
jl_apply_generic at /home/yhls/julia/src/gf.c:2213
unknown function (ip: 0x7f22e0113f3c)
_jl_invoke at /home/yhls/julia/src/gf.c:2049 [inlined]
...

[JeffBezanson]

That looks like an assertion failure. Running julia -g 2 --output-ji x compiler/compiler.jl in base/ will hopefully show the location in the stack trace.

[vchuravy]

bump, would be great to have it in 1.3, but it needs another rebase.

[yhls]

Just rebased. Are we also waiting for me to figure out what goes wrong when DCE in IncrementalCompact is turned on by default again? (I'm still travelling, and won't be able to investigate for a while.)

[vchuravy]

Thanks! This seems more correct in general and we can figure out the other bug later