[PATCH] Fix for PR20059 (instcombine reorders shufflevector after instruction that may trap)

[Arnold Schwaighofer]

I believe the optimization is safe for floating values that cannot trap. 

  undef = fadd undef, %x 

but it does not trap. So the optimization of reordering the shuffle should be safe.

However:

  fdiv %x, undef

can trap because undef can be assumed to be any value including zero. And fdiv traps on zero. So the optimization is not safe.


What does isSafeToSpeculativelyExecute() return for fdiv? It seems to be an omission (bug) that it returns true? (Note, I have not verified this claim but the switch in this function does not contain fdiv and the default case returns true)

At least LICM seems like it could go wrong with conditionally executed fdiv (with loop invariant operands):

bool LICM::isSafeToExecuteUnconditionally(Instruction &Inst) {
  // If it is not a trapping instruction, it is always safe to hoist.
  if (isSafeToSpeculativelyExecute(&Inst))
    return true;

http://reviews.llvm.org/D4424