Hi all,

In this PR we encounter a wrong-code bug on x86_64. It started with an RTL if-conversion patch of mine
which I believe exposed a latent issue in the ree (redundant extension elimination) pass.
The different if-conversion behaviour enabled a new cse opportunity
which then produced the RTL that triggered the bad ree behaviour.
The relevant RTL insns before the ree pass look like:

Basic Block A:
(set (reg:HI 0 ax)
      (mem:HI (symbol_ref:DI ("f"))))
...
(set (reg:SI 3 bx)
      (if_then_else:SI (eq (reg:CCZ 17 flags)
                 (const_int 0))
             (reg:SI 0 ax)
             (reg:SI 3 bx)))

(set (reg:SI 4 si)
      (sign_extend:SI (reg:HI 3 bx)))
...
Basic block B (dominated by basic block A):
(set (reg:SI 4 si)
      (sign_extend:SI (reg:QI 0 ax))) /* ax contains symbol "f". */


ree changes that into the broken:
Basic block A:
(set (reg:SI 4 si)
      (sign_extend:SI (mem:HI (symbol_ref:DI ("f")))))

(set (reg:SI 3 bx)
      (reg:SI 4 si))

...
(set (reg:SI 3 bx)
      (if_then_else:SI (eq (reg:CCZ 17 flags)
                 (const_int 0 [0]))
             (reg:SI 0 ax)
             (reg:SI 3 bx)))
...
Basic block B:
(set (reg:SI 4 si)
      (sign_extend:SI (reg:QI 0 ax))) /* Insn unchanged by ree, but ax now undefined.  */


Note that after ree register ax is now used uninitialised in basic block A and
the insn that previously set it to symbol "f" has now been transformed into:
(set (reg:SI 4 si)
      (sign_extend:SI (mem:HI (symbol_ref:DI ("f")))))

I've explained in the comments in the patch what's going on but the short version is
trying to change the destination of a defining insn that feeds into an extend insn
is not valid if the defining insn doesn't feed directly into the extend insn.
In the ree pass the only way this can happen is if there is an intermediate conditional
move that the pass tries to handle in a special way.  An equivalent fix would have been
to check on that path (when copy_needed in combine_reaching_defs is true) that the
state->copies_list vector (that contains the conditional move insns feeding into the
extend insn) is empty.

This patch is the minimal fix that I could do for this PR and the cases it rejects are
cases where we're pretty much guaranteed to miscompile the code, so it doesn't reject
any legitimate extension elimination opportunities. I checked that the code generation
doesn't change on aarch64 for the whole of SPEC2006 (I did see codegen regressions with
previous versions of the patch that were less targeted).

Bootstrapped and tested on x86_64-unknown-linux-gnu, arm-none-linux-gnueabihf,
aarch64-none-linux-gnu.

I've marked some other PRs that are dups of this one in the ChangeLog. If anyone
has any other PRs that are dups of this one please let me know.

Ok for trunk?

Thanks,
Kyrill

2015-11-16  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR rtl-optimization/68194
     PR rtl-optimization/68328
     PR rtl-optimization/68185
     * ree.c (combine_reaching_defs): Reject copy_needed case if defining
     insn does not feed directly into candidate extension insn.

2015-11-16  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR rtl-optimization/68194
     * gcc.dg/pr68194.c: New test.