[Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms

[akyrtzi]

Summary

Adds nanosecond precision for the time reported for getLastAccessedTime() and getLastModificationTime() for unix platforms that support improved precision.
Previously those functions would only provide times in 1 second resolution, even when the underlying file system could provide more precise times than that.

Also add some comments to make sure people are aware that the resolution of times can vary across different file systems.

[akyrtzi]

Moved the toTimePoint conversion function to llvm/Support/Chrono.h so it can be broadly available.

[kristina]

Do we really need nanosecond precision with regards to this? The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added. However, if there's no consumer for such API (pending review) there is no point in adding it. The main spirit of the library is to only provide what LLVM and related projects require, I don't think nanosecond precision support falls within that category (unless what I said earlier is the case, in which case please link it to this revision).

[akyrtzi]

The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added

There have been enhancements to file_status that added more info without the requirement you stated (attach related revisions to this one), like:
https://reviews.llvm.org/D31110
https://reviews.llvm.org/D18456

This patch makes no changes to the existing API so there's no specific place that I can point to, but it improves accuracy of *every* site that calls getLastModification() and uses its value for comparisons, in and out-of-tree. It addresses 'false-negatives' (mistakenly considering that the mod time did not change because the change happened within 1 second) and 'false-positives' (when considering same mod time as 'changed' so as to be conservative against sub-second changes).
For some examples:
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Frontend/PrecompiledPreamble.cpp#L486
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/Driver.cpp#L1132
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/ToolChains/Clang.cpp#L2623
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Serialization/ModuleManager.cpp#L156
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Index/IndexUnitWriter.cpp#L252
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/DirectoryWatcher/DirectoryWatcher-linux.inc.h#L33

Apart from improving accuracy of mod time comparisons inside clang and its libraries themselves, mod times originating from clang libraries get reported up to our indexing system where we could take advantage of sub-second accuracy, for the same kind of benefits.

[akyrtzi]

if there's no consumer for such API (pending review) there is no point in adding it.

To make sure it's clear, this is not a new API. getLastModificationTime() already reports a a timepoint in nanoseconds, but it is always in second intervals. This patch allows it to include the nanoseconds that are part of the underlying file status.

[lebedev.ri]

In D54826#1307383, @akyrtzi wrote:

The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added

There have been enhancements to file_status that added more info without the requirement you stated (attach related revisions to this one), like:
https://reviews.llvm.org/D31110
https://reviews.llvm.org/D18456

This patch makes no changes to the existing API so there's no specific place that I can point to, but it improves accuracy of *every* site that calls getLastModification() and uses its value for comparisons, in and out-of-tree. It addresses 'false-negatives'

(mistakenly considering that the mod time did not change because the change happened within 1 second)

I think this is the most important bit of information here. It should have been in the description of the differential.
If the current precision was 1ms (or even 1us), then yes, going all the way down to 1ns may not be important/worthwhile.
But 1 sec precision is clearly laughably not great, and should be improved.

and 'false-positives' (when considering same mod time as 'changed' so as to be conservative against sub-second changes).
For some examples:
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Frontend/PrecompiledPreamble.cpp#L486
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/Driver.cpp#L1132
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/ToolChains/Clang.cpp#L2623
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Serialization/ModuleManager.cpp#L156
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Index/IndexUnitWriter.cpp#L252
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/DirectoryWatcher/DirectoryWatcher-linux.inc.h#L33

Apart from improving accuracy of mod time comparisons inside clang and its libraries themselves, mod times originating from clang libraries get reported up to our indexing system where we could take advantage of sub-second accuracy, for the same kind of benefits.

[akyrtzi]

On second look, if you are concerned with adding additional fields in basic_file_status, I can replace:

time_t fs_st_atime = 0;
time_t fs_st_mtime = 0;

with uint64_t's which are adequate to include nanosecond precision, while these time_t's are 64bits as well but waste space in the structure.

[aaron.ballman]

In D54826#1307383, @akyrtzi wrote:

The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added

There have been enhancements to file_status that added more info without the requirement you stated (attach related revisions to this one), like:
https://reviews.llvm.org/D31110
https://reviews.llvm.org/D18456

This patch makes no changes to the existing API so there's no specific place that I can point to, but it improves accuracy of *every* site that calls getLastModification() and uses its value for comparisons, in and out-of-tree. It addresses 'false-negatives' (mistakenly considering that the mod time did not change because the change happened within 1 second) and 'false-positives' (when considering same mod time as 'changed' so as to be conservative against sub-second changes).

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

For some examples:
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Frontend/PrecompiledPreamble.cpp#L486
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/Driver.cpp#L1132
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Driver/ToolChains/Clang.cpp#L2623
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Serialization/ModuleManager.cpp#L156
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/Index/IndexUnitWriter.cpp#L252
https://github.com/apple/swift-clang/blob/95cdf7c9af0dc102a3fbda4ae1f6265026ff2e30/lib/DirectoryWatcher/DirectoryWatcher-linux.inc.h#L33

Apart from improving accuracy of mod time comparisons inside clang and its libraries themselves, mod times originating from clang libraries get reported up to our indexing system where we could take advantage of sub-second accuracy, for the same kind of benefits.

[akyrtzi]

I think this is the most important bit of information here. It should have been in the description of the differential.
If the current precision was 1ms (or even 1us), then yes, going all the way down to 1ns may not be important/worthwhile.
But 1 sec precision is clearly laughably not great, and should be improved.

Ah good point, I didn't consider that people are not broadly aware that current file_status has only 'up to second' precision.

[kristina]

I think your original patch is fine, with better explanation of the reasoning behind it. I would comment on the platform differences with regards to modification time precision, it will make it easier to understand the rationale whenever someone is reading/reviewing related code in the future, IMO.

I'd also suggest elaborating on that point in the commit message since the actual purpose of the patch is vague from its description.

[akyrtzi]

In D54826#1307402, @aaron.ballman wrote:

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

I can't speak for the Windows side of things but what you are pointing out is a general question about applications taking into account that file properties may differ across platforms. This is orthogonal to file_status itself reporting file properties accurately.
If current file_status has 1 hour resolution on NTFS for access time, this patch is not going to make it any better or worse, nor affect behavior of applications that are querying files from NTFS.

[kristina]

In D54826#1307402, @aaron.ballman wrote:

In D54826#1307383, @akyrtzi wrote:

The general changes to the support libraries are usually facilitated because of missing functionality that is required somewhere else and it being the most logical place to add it. If so please attach related revisions to this one (through "Edit Related Revisions") so it's more clear why this was added

There have been enhancements to file_status that added more info without the requirement you stated (attach related revisions to this one), like:
https://reviews.llvm.org/D31110
https://reviews.llvm.org/D18456

This patch makes no changes to the existing API so there's no specific place that I can point to, but it improves accuracy of *every* site that calls getLastModification() and uses its value for comparisons, in and out-of-tree. It addresses 'false-negatives' (mistakenly considering that the mod time did not change because the change happened within 1 second) and 'false-positives' (when considering same mod time as 'changed' so as to be conservative against sub-second changes).

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

Unfortunately there isn't a lot that can be done about that short of keeping a separate index of files and their timestamps, which seems to be slightly overkill, it's unlikely to affect anything unless you have a setup with different filesystems and are crossing mountpoints but I don't think this is significant enough to consider here. And with regards to NTFS, there really isn't much to be done unless you want to settle on microsecond precision instead as some sort of a universal thing, but that won't cover everything since there are just too many platforms and filesystems to consider besides NTFS, HFS+, APFS and Ext4, there are many others including some using network mounts or ramdisks.

[aaron.ballman]

In D54826#1307407, @akyrtzi wrote:

In D54826#1307402, @aaron.ballman wrote:

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

I can't speak for the Windows side of things but what you are pointing out is a general question about applications taking into account that file properties may differ across platforms. This is orthogonal to file_status itself reporting file properties accurately.

It is and it isn't. This is a cross-platform API and users may expect the values to be somewhat similarly reported across platforms, especially given that there is no documentation on getLastAccessedTime() or getLastModificationTime().

If current file_status has 1 hour resolution on NTFS for access time, this patch is not going to make it any better or worse, nor affect behavior of applications that are querying files from NTFS.

Agreed, and I wasn't suggesting that it would. I was more wondering whether you had thoughts on people using this across platforms where they will get very different behavior from the same API. Personally, I think it's reasonable to report the values with whatever precision we have available to us. I think that should be documented on the public API part with a mention that the resolution is expected to differ depending on the file system and OS. WDYT?

[kristina]

In D54826#1307402, @aaron.ballman wrote:

Is it going to be an issue that the Windows side of things has a more wild idea of file timestamp resolution? NTFS has a theoretical max precision of 100ns intervals, though according to MSDN, the access time on NTFS has a resolution of 1 hour, which is better than FAT file systems, where the resolution is 1 day. It seems odd to rely on ns resolution for access time, as that seems like it's going to be highly platform and filesystem dependent.

I can't speak for the Windows side of things but what you are pointing out is a general question about applications taking into account that file properties may differ across platforms. This is orthogonal to file_status itself reporting file properties accurately.

It is and it isn't. This is a cross-platform API and users may expect the values to be somewhat similarly reported across platforms, especially given that there is no documentation on getLastAccessedTime() or getLastModificationTime().

If current file_status has 1 hour resolution on NTFS for access time, this patch is not going to make it any better or worse, nor affect behavior of applications that are querying files from NTFS.

Agreed, and I wasn't suggesting that it would. I was more wondering whether you had thoughts on people using this across platforms where they will get very different behavior from the same API. Personally, I think it's reasonable to report the values with whatever precision we have available to us. I think that should be documented on the public API part with a mention that the resolution is expected to differ depending on the file system and OS. WDYT?

Yes, I can update the documentation for LLVMSupport, definitely worth mentioning it, I think it's worth dropping a comment there as well, as it seems that if someone does hit issues with it, it may be a very annoying thing to debug.

[kristina]

With regards to UNIX-style access/modification times, the options are to find a uniform duration for all file-systems that is clamped to the one with lowest precision (like 1us), or just settle for this as-is. Though having this documented would be good, going on a hunt to determine the quirks of each possible file-system may be pretty difficult, especially considering some may allow tuning of those values.

[aaron.ballman]

Aside from a minor consistency nit, I think this LGTM. I don't think there's a reasonable way to test this behavior, so it's fine to go in without a test.

include/llvm/Config/config.h.cmake

212 ↗

(On Diff #175062)

Is there a reason to not use #cmakedefine like the other uses?

lib/Support/Unix/Path.inc

595 ↗

(On Diff #175062)

...and switch these to using #ifdef or #if defined().

[aaron.ballman]

In D54826#1307420, @kristina wrote:

With regards to UNIX-style access/modification times, the options are to find a uniform duration for all file-systems that is clamped to the one with lowest precision (like 1us), or just settle for this as-is. Though having this documented would be good, going on a hunt to determine the quirks of each possible file-system may be pretty difficult, especially considering some may allow tuning of those values.

Yeah, I agree that some simple comments here should suffice. We don't need to document the behavior of each file system, just some words to remind people that file systems can differ should work fine.

[akyrtzi]

I think that should be documented on the public API part with a mention that the resolution is expected to differ depending on the file system and OS. WDYT?

That is a good idea, the way I consider file_status is that it provides a cross-platform way to get at the file properties. It provides times in nanoseconds but leaves the precision as implementation detail of the underlying file system, which makes sense, people should not expect anything more than that.
I'll add some comments.

[akyrtzi]

include/llvm/Config/config.h.cmake

212 ↗

(On Diff #175062)

This file is not consistent on what it uses, it has uses of #cmakedefine01 in some places but majority is with #cmakedefine.
I mainly liked to use #if HAVE_STRUCT_STAT.. directly since it reads more naturally, but if you prefer it the other way I will switch.

[aaron.ballman]

include/llvm/Config/config.h.cmake

212 ↗

(On Diff #175062)

I don't have a strong opinion; I just noticed everything around it in the patch context was using #cmakedefine. I have a weak preference for #cmakedefine because the resulting macro cannot produce a value (it can only be used in a conditional preprocessor test). The strength of that argument should tell you about how strong my preference is. ;-)

[akyrtzi]

include/llvm/Config/config.h.cmake

212 ↗

(On Diff #175062)

I'm persuaded by the argument that the majority in the file uses #cmakedefine, I'll change it so consistency can slightly improve ;-)

[akyrtzi]

• Change #cmakedefine01 to #cmakedefine for consistency.
• Add comments to getLastAccessedTime()/ getLastModificationTime() APIs to make sure people are aware that time resolution can differ among file systems.
• Improve commit summary.

[aaron.ballman]

LGTM!

[akyrtzi]

Thanks for reviewing Kristina & Aaron, much appreciated!

[thakis]

llvm/trunk/include/llvm/Config/config.h.cmake

215

Putting this in the middle of the HAVE_SYS_ defines is a bit of a surprising place. Maybe put it above all the HAVE_SYS_ thingies so that it's at least locally alphabetical?

[akyrtzi]

llvm/trunk/include/llvm/Config/config.h.cmake

215

There's some debate in https://reviews.llvm.org/D54883 whether the CMake checks should be used or not, once this is settled I'll see about making such a change.

llvm/trunk/cmake/config-ix.cmake

 if( WIN32 AND NOT CYGWIN )
   # We consider Cygwin as another Unix
   set(PURE_WINDOWS 1)
 endif()
 
 include(CheckIncludeFile)
 include(CheckLibraryExists)
 include(CheckSymbolExists)
 include(CheckFunctionExists)
+include(CheckStructHasMember)
 include(CheckCCompilerFlag)
 
 include(CheckCompilerVersion)
 include(HandleLLVMStdlib)
 
 if( UNIX AND NOT (BEOS OR HAIKU) )
   # Used by check_symbol_exists:
   list(APPEND CMAKE_REQUIRED_LIBRARIES "m")
if( HAVE_DLFCN_H )
   endif()
   check_symbol_exists(dlopen dlfcn.h HAVE_DLOPEN)
   check_symbol_exists(dladdr dlfcn.h HAVE_DLADDR)
   if( HAVE_LIBDL )
     list(REMOVE_ITEM CMAKE_REQUIRED_LIBRARIES dl)
   endif()
 endif()
 
+CHECK_STRUCT_HAS_MEMBER("struct stat" st_mtimespec.tv_nsec
+    "sys/types.h;sys/stat.h" HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC)
+CHECK_STRUCT_HAS_MEMBER("struct stat" st_mtim.tv_nsec
+    "sys/types.h;sys/stat.h" HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC)
+
 check_symbol_exists(__GLIBC__ stdio.h LLVM_USING_GLIBC)
 if( LLVM_USING_GLIBC )
   add_definitions( -D_GNU_SOURCE )
   list(APPEND CMAKE_REQUIRED_DEFINITIONS "-D_GNU_SOURCE")
 endif()
 # This check requires _GNU_SOURCE
 check_symbol_exists(sched_getaffinity sched.h HAVE_SCHED_GETAFFINITY)
 check_symbol_exists(CPU_COUNT sched.h HAVE_CPU_COUNT)

llvm/trunk/include/llvm/Config/config.h.cmake

 #cmakedefine HAVE_SYS_RESOURCE_H ${HAVE_SYS_RESOURCE_H}
 
 /* Define to 1 if you have the <sys/stat.h> header file. */
 #cmakedefine HAVE_SYS_STAT_H ${HAVE_SYS_STAT_H}
 
 /* Define to 1 if you have the <sys/time.h> header file. */
 #cmakedefine HAVE_SYS_TIME_H ${HAVE_SYS_TIME_H}
 
+/* Define to 1 if stat struct has st_mtimespec member .*/
+#cmakedefine HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC ${HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC}
+
+/* Define to 1 if stat struct has st_mtim member. */
+#cmakedefine HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC ${HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC}
+
 /* Define to 1 if you have the <sys/types.h> header file. */
 #cmakedefine HAVE_SYS_TYPES_H ${HAVE_SYS_TYPES_H}
 
 /* Define if the setupterm() function is supported this platform. */
 #cmakedefine HAVE_TERMINFO ${HAVE_TERMINFO}
 
 /* Define if the xar_open() function is supported this platform. */
 #cmakedefine HAVE_LIBXAR ${HAVE_LIBXAR}

llvm/trunk/include/llvm/Support/Chrono.h

 
 /// Convert a std::time_t to a TimePoint
 LLVM_ATTRIBUTE_ALWAYS_INLINE inline TimePoint<std::chrono::seconds>
 toTimePoint(std::time_t T) {
   using namespace std::chrono;
   return time_point_cast<seconds>(system_clock::from_time_t(T));
 }
 
+/// Convert a std::time_t + nanoseconds to a TimePoint
+LLVM_ATTRIBUTE_ALWAYS_INLINE inline TimePoint<>
+toTimePoint(std::time_t T, uint32_t nsec) {
+  using namespace std::chrono;
+  return time_point_cast<nanoseconds>(system_clock::from_time_t(T))
+    + nanoseconds(nsec);
+}
+
 } // namespace sys
 
 raw_ostream &operator<<(raw_ostream &OS, sys::TimePoint<> TP);
 
 /// Format provider for TimePoint<>
 ///
 /// The options string is a strftime format string, with extensions:
 ///   - %L is millis: 000-999

llvm/trunk/include/llvm/Support/FileSystem.h

 /// Represents the result of a call to directory_iterator::status(). This is a
 /// subset of the information returned by a regular sys::fs::status() call, and
 /// represents the information provided by Windows FileFirstFile/FindNextFile.
 class basic_file_status {
 protected:
   #if defined(LLVM_ON_UNIX)
   time_t fs_st_atime = 0;
   time_t fs_st_mtime = 0;
+  uint32_t fs_st_atime_nsec = 0;
+  uint32_t fs_st_mtime_nsec = 0;
   uid_t fs_st_uid = 0;
   gid_t fs_st_gid = 0;
   off_t fs_st_size = 0;
   #elif defined (_WIN32)
   uint32_t LastAccessedTimeHigh = 0;
   uint32_t LastAccessedTimeLow = 0;
   uint32_t LastWriteTimeHigh = 0;
   uint32_t LastWriteTimeLow = 0;
   uint32_t FileSizeHigh = 0;
   uint32_t FileSizeLow = 0;
   #endif
   file_type Type = file_type::status_error;
   perms Perms = perms_not_known;
 
 public:
   basic_file_status() = default;
 
   explicit basic_file_status(file_type Type) : Type(Type) {}
 
   #if defined(LLVM_ON_UNIX)
-  basic_file_status(file_type Type, perms Perms, time_t ATime, time_t MTime,
+  basic_file_status(file_type Type, perms Perms, time_t ATime,
+                    uint32_t ATimeNSec, time_t MTime, uint32_t MTimeNSec,
                     uid_t UID, gid_t GID, off_t Size)
-      : fs_st_atime(ATime), fs_st_mtime(MTime), fs_st_uid(UID), fs_st_gid(GID),
+      : fs_st_atime(ATime), fs_st_mtime(MTime),
+        fs_st_atime_nsec(ATimeNSec), fs_st_mtime_nsec(MTimeNSec),
+        fs_st_uid(UID), fs_st_gid(GID),
         fs_st_size(Size), Type(Type), Perms(Perms) {}
 #elif defined(_WIN32)
   basic_file_status(file_type Type, perms Perms, uint32_t LastAccessTimeHigh,
                     uint32_t LastAccessTimeLow, uint32_t LastWriteTimeHigh,
                     uint32_t LastWriteTimeLow, uint32_t FileSizeHigh,
                     uint32_t FileSizeLow)
       : LastAccessedTimeHigh(LastAccessTimeHigh),
         LastAccessedTimeLow(LastAccessTimeLow),
         LastWriteTimeHigh(LastWriteTimeHigh),
         LastWriteTimeLow(LastWriteTimeLow), FileSizeHigh(FileSizeHigh),
         FileSizeLow(FileSizeLow), Type(Type), Perms(Perms) {}
   #endif
 
   // getters
   file_type type() const { return Type; }
   perms permissions() const { return Perms; }
+
+  /// The file access time as reported from the underlying file system.
+  ///
+  /// Also see comments on \c getLastModificationTime() related to the precision
+  /// of the returned value.
   TimePoint<> getLastAccessedTime() const;
+
+  /// The file modification time as reported from the underlying file system.
+  ///
+  /// The returned value allows for nanosecond precision but the actual
+  /// resolution is an implementation detail of the underlying file system.
+  /// There is no guarantee for what kind of resolution you can expect, the
+  /// resolution can differ across platforms and even across mountpoints on the
+  /// same machine.
   TimePoint<> getLastModificationTime() const;
 
   #if defined(LLVM_ON_UNIX)
   uint32_t getUser() const { return fs_st_uid; }
   uint32_t getGroup() const { return fs_st_gid; }
   uint64_t getSize() const { return fs_st_size; }
   #elif defined (_WIN32)
   uint32_t getUser() const {

 
 public:
   file_status() = default;
 
   explicit file_status(file_type Type) : basic_file_status(Type) {}
 
   #if defined(LLVM_ON_UNIX)
   file_status(file_type Type, perms Perms, dev_t Dev, nlink_t Links, ino_t Ino,
-              time_t ATime, time_t MTime, uid_t UID, gid_t GID, off_t Size)
-      : basic_file_status(Type, Perms, ATime, MTime, UID, GID, Size),
+              time_t ATime, uint32_t ATimeNSec,
+              time_t MTime, uint32_t MTimeNSec,
+              uid_t UID, gid_t GID, off_t Size)
+      : basic_file_status(Type, Perms, ATime, ATimeNSec, MTime, MTimeNSec,
+                          UID, GID, Size),
         fs_st_dev(Dev), fs_st_nlinks(Links), fs_st_ino(Ino) {}
   #elif defined(_WIN32)
   file_status(file_type Type, perms Perms, uint32_t LinkCount,
               uint32_t LastAccessTimeHigh, uint32_t LastAccessTimeLow,
               uint32_t LastWriteTimeHigh, uint32_t LastWriteTimeLow,
               uint32_t VolumeSerialNumber, uint32_t FileSizeHigh,
               uint32_t FileSizeLow, uint32_t FileIndexHigh,
               uint32_t FileIndexLow)

llvm/trunk/lib/Support/Unix/Path.inc

if (realpath(DLInfo.dli_fname, link_path))
     return link_path;
 #else
 #error GetMainExecutable is not implemented on this host yet.
 #endif
   return "";
 }
 
 TimePoint<> basic_file_status::getLastAccessedTime() const {
-  return toTimePoint(fs_st_atime);
+  return toTimePoint(fs_st_atime, fs_st_atime_nsec);
 }
 
 TimePoint<> basic_file_status::getLastModificationTime() const {
-  return toTimePoint(fs_st_mtime);
+  return toTimePoint(fs_st_mtime, fs_st_mtime_nsec);
 }
 
 UniqueID file_status::getUniqueID() const {
   return UniqueID(fs_st_dev, fs_st_ino);
 }
 
 uint32_t file_status::getLinkCount() const {
   return fs_st_nlinks;
if (StatRet != 0) {
     std::error_code EC(errno, std::generic_category());
     if (EC == errc::no_such_file_or_directory)
       Result = file_status(file_type::file_not_found);
     else
       Result = file_status(file_type::status_error);
     return EC;
   }
 
+  uint32_t atime_nsec, mtime_nsec;
+#if defined(HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC)
+  atime_nsec = Status.st_atimespec.tv_nsec;
+  mtime_nsec = Status.st_mtimespec.tv_nsec;
+#elif defined(HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC)
+  atime_nsec = Status.st_atim.tv_nsec;
+  mtime_nsec = Status.st_mtim.tv_nsec;
+#else
+  atime_nsec = mtime_nsec = 0;
+#endif
+
   perms Perms = static_cast<perms>(Status.st_mode) & all_perms;
   Result = file_status(typeForMode(Status.st_mode), Perms, Status.st_dev,
-                       Status.st_nlink, Status.st_ino, Status.st_atime,
-                       Status.st_mtime, Status.st_uid, Status.st_gid,
-                       Status.st_size);
+                       Status.st_nlink, Status.st_ino,
+                       Status.st_atime, atime_nsec, Status.st_mtime, mtime_nsec,
+                       Status.st_uid, Status.st_gid, Status.st_size);
 
   return std::error_code();
 }
 
 std::error_code status(const Twine &Path, file_status &Result, bool Follow) {
   SmallString<128> PathStorage;
   StringRef P = Path.toNullTerminatedStringRef(PathStorage);