This is an archive of the discontinued LLVM Phabricator instance.

Return undef on conversions that overflow (PR21330).
ClosedPublic

Authored by spatel on Oct 3 2014, 9:35 AM.

Details

Summary

The LLVM Lang Ref states for signed/unsigned int to float conversions:
"If the value cannot fit in the floating point value, the results are undefined."

And for FP to signed/unsigned int:
"If the value cannot fit in ty2, the results are undefined."

This matches the C definitions.

The existing behavior pins to infinity or a max int value, but that may just lead to more confusion as seen in:
http://llvm.org/bugs/show_bug.cgi?id=21130

Returning undef will hopefully lead to a less silent failure.

Diff Detail

Repository
rL LLVM

Event Timeline

spatel updated this revision to Diff 14384.Oct 3 2014, 9:35 AM
spatel retitled this revision from to Return undef on conversions that overflow (PR21330)..
spatel updated this object.
spatel edited the test plan for this revision. (Show Details)
spatel added reviewers: asl, hfinkel, sylvestre.ledru.
spatel added a subscriber: Unknown Object (MLST).
hfinkel edited edge metadata.Oct 9 2014, 8:15 PM

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

hfinkel accepted this revision.Oct 10 2014, 10:25 AM
hfinkel edited edge metadata.

Okay; fair enough. LGTM.

This revision is now accepted and ready to land.Oct 10 2014, 10:25 AM
spatel closed this revision.Oct 10 2014, 4:10 PM
spatel updated this revision to Diff 14755.

Closed by commit rL219542 (authored by @spatel).