r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Robinson, Paul via cfe-commits]

| Oh right, sorry, off-by-one error when evaluating that by hand; I got 0x7fffffff (which is also a NaN, 0x7fc00000 is not the only NaN).
No worries.

| http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you get an undefined result for overflow currently.
Other parts of the LangRef are comfortable talking about infinities, e.g. there's a way to write them as constants, and IEEE float is pervasive in this era, so it would seem consistent for uitofp to return +infinity for the overflow case.  I'm not the one to propose it, though. ☺
--paulr

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith
Sent: Wednesday, December 09, 2015 12:43 PM
To: Robinson, Paul
Cc: Joerg Sonnenberger; cfe-commits (cfe-commits at lists.llvm.org)
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits <cfe-commits at lists.llvm.org<mailto:cfe-commits at lists.llvm.org>> wrote:
| And at runtime, on some targets, we use this:
|
|  https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c
|
| ... which gives a NaN in this case.

I copied that function into a test program on Ubuntu, built with gcc, and it gives me +Infinity (0x7f800000) not NaN (0x7fc00000).

Oh right, sorry, off-by-one error when evaluating that by hand; I got 0x7fffffff (which is also a NaN, 0x7fc00000 is not the only NaN).

So, I think the question is, do we want to update LLVM to define the value of an out-of-range uitofp (and "fix" any targets that don't give +/- Inf for these conversions)? http://llvm.org/docs/LangRef.html#uitofp-to-instruction is clear that you get an undefined result for overflow currently.

In (AFAICS) all supported targets, for integer types supported by clang, there are only two ways to hit the overflow case:
 1) uint128 -> float
 2) uint64 or larger -> half

Case (1) goes through uitofp (which explicitly says the result is undefined at the moment), case (2) goes via @llvm.convert.to.fp16 (which says nothing about what happens in this case, but presumably it is defined). These are both phenomenally rare conversions, so adding (potential) extra cost to them to make them handle the out-of-range case correctly doesn't seem unreasonable.

--paulr

From: metafoo at gmail.com<mailto:metafoo at gmail.com> [mailto:metafoo at gmail.com<mailto:metafoo at gmail.com>] On Behalf Of Richard Smith
Sent: Tuesday, December 08, 2015 11:42 AM
To: Robinson, Paul
Cc: Joerg Sonnenberger; cfe-commits (cfe-commits at lists.llvm.org<mailto:cfe-commits at lists.llvm.org>)

Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith <richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>> wrote:
On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
Okay, I'll bite:  so what *does* UINT128_MAX actually convert to?

$ echo 'unsigned __int128 max = -1; float f = max;' | ~/clang-8/build/bin/clang -x c++ - -emit-llvm -S -o - -O3 | grep @f
@f = global float undef, align 4

And at runtime, on some targets, we use this:

  https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c

... which gives a NaN in this case.

From: cfe-commits [mailto:cfe-commits-bounces at lists.llvm.org<mailto:cfe-commits-bounces at lists.llvm.org>] On Behalf Of Richard Smith via cfe-commits
Sent: Tuesday, December 08, 2015 10:52 AM
To: Joerg Sonnenberger; cfe-commits
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits <cfe-commits at lists.llvm.org<mailto:cfe-commits at lists.llvm.org>> wrote:
On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote:
> C11 6.3.1.5/1<http://6.3.1.5/1>: "If the value being converted is outside the range of values
> that can be represented, the behavior is undefined."

The value of 1e100 can be represented as +inf, even if not precisely.

Only if +inf is in the range of representable values, which, as already noted, is problematic.

This is a bit different from non-IEEE math like VAX, that doesn't have
infinities.

Joerg
_______________________________________________
cfe-commits mailing list
cfe-commits at lists.llvm.org<mailto:cfe-commits at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits




_______________________________________________
cfe-commits mailing list
cfe-commits at lists.llvm.org<mailto:cfe-commits at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151209/bae2aeb0/attachment-0001.html>