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

[Chris Lattner]

>> 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.

Ug, excellent point.  At this point, I'm inclined to just give up  
folding of udiv undefs.  What do you think?

> 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!

Fortunately, this isn't a problem.  LLVM has no copy instruction, so  
the code is really this:

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

There is nothing that specifies the two undefs are the same value.   
Also, in C, if you have an undefined variable, you aren't guaranteed  
to get the same undef value each time you read the variable, so  
transforming C into LLVM is ok :)

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

Hopefully I'll check in a new parser in a few weeks for llvm that  
accepts something very *very* similar to C. :)

-Chris