On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits < cfe-commits@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:* meta...@gmail.com [mailto:meta...@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@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 <rich...@metafoo.co.uk> > wrote: > > On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul < > paul_robin...@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-boun...@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@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: "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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > > > > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
