wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.

For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.

For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.

In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.

The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.

The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.

llvm-svn: 171551

utils/sort_includes.py script.

Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.

llvm-svn: 171362

users over to the new one. No sense maintaining this "compatibility"
layer it seems.

llvm-svn: 171331

Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.

llvm-svn: 171330

Fix a truly odd namespace qualifier that was flat out wrong in the
process. The fully qualified namespace would have been
llvm::sys::TimeValue, llvm::TimeValue makes no sense.

llvm-svn: 171292

llvm-svn: 171291

llvm-svn: 171290

The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.

This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.

However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.

llvm-svn: 171289

FIXME: GetRandomNumber() is not implemented in Win32.
llvm-svn: 156251

llvm-svn: 156240

 - Primitive API, but we rarely have need for random numbers.

llvm-svn: 156237

llvm-svn: 120298

llvm-svn: 50695

llvm-svn: 45418

Put the rest of lib/System into LinkAllVMCore.h. This makes all of
lib/System available to programs that #include LinkALlVMCore.h so that
loadable modules linked into those programs can depend on all of lib/System
being available.

llvm-svn: 29288

llvm-svn: 21704

llvm-svn: 21422

gdb debugger doesn't get confused on which file it is reading (the one in
lib/System or the one in lib/System/{Win32,Unix})

llvm-svn: 19426

* Consolidate implementation for Unix systems into Unix/Process.cpp
* Avoid use of symbolic link to #include platform-specific implementation.

llvm-svn: 19150

platforms.
Implement GetLLVMSuffix function for the Path concept.

llvm-svn: 16292

"Program" operating system concept (find and execute programs).

llvm-svn: 16084

note individually but these essence of it is to not derive from
std::string, clarify the interface, and provide better documentation.
There is now also (untested) implementations for AIX, Darwin, and SunOS.

llvm-svn: 16078

llvm-svn: 16048

provided.

llvm-svn: 15816

llvm-svn: 15763