[PATCH] Return undef on conversions that overflow (PR21330).

[Sanjay Patel]

>>! In D5603#4, @hfinkel wrote:
> I suppose the real question here is: Should we provide "best effort", and can we define what that means? What does common hardware do? 
> Can you explain how making this undef will help the test case from the PR(s)?

In http://llvm.org/bugs/show_bug.cgi?id=21130, our best effort based on the current behavior was to saturate to the max signed int value (127 for an i8). But this result was considered wrong by the customer. They expected the unsigned 8-bit value (0x9c) to be generated and then be interpreted as a signed value -100. 

I'm not sure how we'd pick a winner based on that, so I would hope that an undef return would eventually generate something obviously wrong (like a zero instruction on PPC or a ud2 on x86)? I haven't traced undef codegen through the backend yet.

As for HW behavior, it's a mixed bag. Start with float -> (un)signed int: PPC and x86 don't have instructions for unsigned conversions AFAICT. Their signed conversions try to saturate to the max value...but that doesn't make sense if the conversion was supposed to be unsigned in the high-level language. ARMv8 does have instructions for both signed and unsigned conversions, and it appears to try to saturate in all cases. Int -> float can't overflow for any HW that I see because there's no HW with big enough ints yet. :) So that's just a software problem, and so I'd again take the Lang Ref at its word and return undef.

http://reviews.llvm.org/D5603