This is an archive of the discontinued LLVM Phabricator instance.

cmath: Skip Libc for integral types in isinf, etc.
ClosedPublic

Authored by dexonsmith on Mar 31 2017, 7:03 PM.

Details

Summary

For std::isinf, the standard requires effectively calling isinf as
double from Libc for integral types. But integral types are never
infinite; we don't need to call Libc to return false.

Also short-circuit other functions where Libc won't have interesting
answers: signbit, fpclassify, isfinite, isnan, and isnormal.

I added correctness tests for integral types since we're no longer
deferring to Libc.

Diff Detail

Event Timeline

dexonsmith created this revision.Mar 31 2017, 7:03 PM
hfinkel added inline comments.
libcxx/include/math.h
354–356

I think that it would be safer / easier to understand if we used !std::is_integral here. It is true for all standard types that std::is_arithmetic implies is_integral or is_floating_point, but it seems likely that some implementations have arithemtic types that are neither (e.g. fixed-point types), and user-defined types seem likely.

404

Maybe we should predicate this, and other infinity-related functions, on std::numeric_limits<_A1>::has_infinity. That seems more general, and safer for potential user-defined types.

dexonsmith updated this revision to Diff 94750.Apr 10 2017, 3:18 PM

Responding to Hal's comments.

dexonsmith marked 2 inline comments as done.Apr 10 2017, 3:20 PM

Marking Hal's comments as "Done". Thanks for the review.

I'm happy with this now. @EricWF , @mclow.lists , thoughts?

EricWF accepted this revision.Apr 12 2017, 11:02 PM

LGTM minus inline comments.

libcxx/include/math.h
354–356

@dexonsmith Could you please codify this point in a comment above the function. My initial reaction was "Why aren't we using std::is_floating_point instead".

This revision is now accepted and ready to land.Apr 12 2017, 11:02 PM
mclow.lists added inline comments.Apr 18 2017, 4:44 PM
libcxx/include/math.h
404

I don't think we need to worry about user-defined types. The standard limits the parameters to "arithmetic types" and in [basic.fundamental] it lists exactly what those types are.

Marshall, that's what I assumed originally, but I figured Hal had some non-standard-but-worth-supporting use case in mind.

Hal, what do you think?

Eric: somehow I never got an email notification for your review :/. If Marshall is okay with the current state, I'll document that before commit.

hfinkel edited edge metadata.Apr 19 2017, 8:49 PM

Marshall, that's what I assumed originally, but I figured Hal had some non-standard-but-worth-supporting use case in mind.

In this case, future-proofing and mathematical precision seemed aligned. I suspect that we'll end up with fixed-point types, etc. at some point, and users already certainly have such types (although it is true that using those types with the std:: math functions is not something we're required to support).

Hal, what do you think?

I think that it is fine either way. Marshall is certainly correct, there are no types we're required to support that makes this a meaningful distinction.

Marshall, are you fine with figuring this out in-tree? Or should I revert to using std::is_floating_point for now?

Since I haven't heard from Marshall and Hal's fine with the less-future-proof std::is_floating_point, I'll commit that and we can iterate in tree. Just running tests.

dexonsmith closed this revision.Apr 21 2017, 4:28 PM

Committed in r301060.