6732194: Data corruption dependent on -server/-client/-Xbatch
Summary: rematerializing nodes results in incorrect inputs
Reviewed-by:

split_Rematerialize is used to rematerialize nodes which either can't
be spilled or for which it is cheaper to recompute the value than the
spill. Rematerializing nodes will lengthen the live ranges of any
inputs to that node and care must be taken that to do that safely.
Some live ranges contain multiple definitions as a result of
coalescing and inputs which come from those LRG have to be cloned
because we don't have enough liveness information to safely lengthen
the live range of one def from that LRG. The existing code correctly
checks all the inputs before cloning the node but the walkThru flag
may cause the code to skip back an LRG which is multidef. If that
occurs we should just fall back to the existing input which is
guaranteed to be safe. It would always be safe to ignore walkThru
since it's only purpose appears to increasings the likelihood that an
existing LRG is used instead of a new one being created.

Adding an assert that checked that walkThru didn't lead to multidef
LRG caused a few thousand failures in CTW and quite a few in
refworkload as wel. Even if we do use a multidef LRG there's no
guarantee that it would lead to incorrect execution since it requires
a pretty specific code shape for that. I was unable to develop a
reliable test case and any possible assert mirrors the logic I just
added so it doesn't seem worthwhile.

tested with 32 and 64 bit intel, ctw, nsk, runthese jck