This is an archive of the discontinued LLVM Phabricator instance.

[Format] Add more ways to format numbers
ClosedPublic

Authored by zturner on Oct 11 2016, 9:58 PM.

Details

Summary

This is some preliminary helpers and utilities that I've been working on to support my formatting library. These are all useful independently of the formatting library, and I'm not committing anything related to the library itself until this is more complete. But I think it's a good idea to have this review separately so it can be more focused on the details of formatting logic (negative signs, decimals, etc) rather than library machinery.

Note that the top-level functions being modified here (i.e. write_long, write_ulong, etc) are the same functions used by llvm::raw_ostream::operator<<, so this code is being exercised today (albeit with only one set of trivial parameters)

Diff Detail

Repository
rL LLVM

Event Timeline

zturner updated this revision to Diff 74322.Oct 11 2016, 9:58 PM
zturner retitled this revision from to [Format] Add more ways to format numbers.
zturner updated this object.
zturner added a reviewer: mehdi_amini.
zturner added a subscriber: llvm-commits.

+beanz and timshen, since they both seem interested in this as well.

timshen edited edge metadata.Oct 13 2016, 11:58 AM

I was interested in constexpr-ness of the library, and I have no problem with the direction we are going on that. Changing myself to CC.

timshen added a subscriber: timshen.

Would someone mind taking a look (or adding someone else who might have some feedback)? I have the rest of the library pretty much ready to commit v1, just blocked on this.

beanz accepted this revision.Oct 14 2016, 12:57 PM
beanz edited edge metadata.

@zturner thank you so much for doing this, this looks really great.

This revision is now accepted and ready to land.Oct 14 2016, 12:57 PM
This revision was automatically updated to reflect the committed changes.

A late drive-by.

llvm/trunk/lib/Support/NativeFormatting.cpp
60

Shouldn't this be named formatToBuffer? Or, perhaps more specifically, formatIntegralTypeToBuffer. Since it's a template function that apparently accepts any type for Value, someone might otherwise mistake it for a more general formatter.

76

How very U.S.-centric. Some regions use different characters as separators, and a few don't even group digits in clusters other than three.

133

"Decimal point" or "decimal separator" seems more idiomatic than "decimal sign."

181

Why? Is this important for peformance or portability or something else?

llvm/trunk/unittests/Support/NativeFormatTests.cpp
148

What does "default precision is 0" mean in this context? Do the hex styles allow you to set a precision to something like 2 or 4 so that it always emits a whole number of bytes? If so, how about a test case for that?

245

Weird, I would have expected this to use width rather than precision.

288

s/padd/pad/

345

What's supposed to happen if you try to percent-format an integer other than 0 or 1?

354

How about something greater than 100% to ensure it doesn't chop digits to make it fit in the width?

zturner added inline comments.Oct 26 2016, 11:31 AM
llvm/trunk/lib/Support/NativeFormatting.cpp
60

Yea, I can make that change.

76

LLVM already assumes US-centric localization for everything else, so this being consistent just seems like the right thing to do. I don't know of any properly localized compilers :)

181

Performance. FWIW, the original code for this was in raw_ostream and this patch moves it over here. But the original code did the same thing. Anyway, the TL;DR is: If a number can fit in 32-bits, it's faster to use 32-bit division and mod than 64-bit division and mod.

llvm/trunk/unittests/Support/NativeFormatTests.cpp
345

Whatever integer you give it is multipled by 100 and printed.