[llvm-commits] CVS: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

[Dan Gohman]

>>>> +
>>>> +  // If either operand is undef, the result is undef
>>>> +  if (N0.getOpcode() == ISD::UNDEF || N1.getOpcode() == ISD::UNDEF)
>>>> +    return DAG.getNode(ISD::UNDEF, VT);
>>>> +
>>>>    return SDOperand();
>>>>  }
>>>
>>> This is not safe for sdiv/udiv.  Safe xforms are:
>>>
>>>    // undef / X -> 0
>>>    // X / undef -> undef
>>>
>>> If in doubt, plz check instcombine.
>>
>> Thanks for correcting me on the undef rules. I'll check in a fix
>> for the code soon. For this sdiv/udiv one though, why is undef/X not
>> undef? For any non-zero value of X there's at least one value the
>> undef might have which makes the divide have a non-zero result.
> 
> I think that undef udiv intmax -> 0, no?  If not, plz update  
> instcombine as well.

intmax udiv intmax -> 1.

It seems like folding undef/X to undef isn't safe either though, with
the way it sounds like undef is intended to work. This code:

  %x = udiv i32 undef, %intmax
  %y = udiv i32 %x, 2

will always set %y to 0. Maybe instcombine can fold the second
udiv by looking through its operands, but it can't safely fold the
first. The best it could do is try to fold away all of %x's uses so
that %x isn't needed anymore.

Even simple things like undef+X don't seem to be safe to fold.

  %x = undef;
  if (%x >= 0)
    %z = %y / (%x + 1);         // don't divide by undef!

(offtopic, wouldn't it be nifty to have a parser for LLVM that
used a C-ish expression syntax?).

It seems that only undef*0 and undef+0 and a few similar things
are really safe here. And those aren't specific to undef.

Dan

-- 
Dan Gohman, Cray Inc.