Skip to content
  1. Jan 23, 2013
  2. Jan 22, 2013
  3. Jan 21, 2013
    • Michael Ilseman's avatar
      Introduce a new data structure, the SparseMultiSet, and changes to the MI scheduler to use it. · 3e3194f4
      Michael Ilseman authored
      A SparseMultiSet adds multiset behavior to SparseSet, while retaining SparseSet's desirable properties. Essentially, SparseMultiSet provides multiset behavior by storing its dense data in doubly linked lists that are inlined into the dense vector. This allows it to provide good data locality as well as vector-like constant-time clear() and fast constant time find(), insert(), and erase(). It also allows SparseMultiSet to have a builtin recycler rather than keeping SparseSet's behavior of always swapping upon removal, which allows it to preserve more iterators. It's often a better alternative to a SparseSet of a growable container or vector-of-vector.
      
      llvm-svn: 173064
      3e3194f4
    • Michael J. Spencer's avatar
      [Support] Make test C++03. · b2137101
      Michael J. Spencer authored
      llvm-svn: 173004
      b2137101
  4. Jan 20, 2013
  5. Jan 16, 2013
    • Peter Collingbourne's avatar
      Introduce llvm::sys::getProcessTriple() function. · a51c6ed6
      Peter Collingbourne authored
      In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
      as part of work to allow the user to supply a different default
      target triple at configure time.  This change also affected the JIT.
      However, it is inappropriate to use the default target triple in the
      JIT in most circumstances because this will not necessarily match
      the current architecture used by the process, leading to illegal
      instruction and other such errors at run time.
      
      Introduce the getProcessTriple() function for use in the JIT and
      its clients, and cause the JIT to use it.  On architectures with a
      single bitness, the host and process triples are identical.  On other
      architectures, the host triple represents the architecture of the
      host CPU, while the process triple represents the architecture used
      by the host CPU to interpret machine code within the current process.
      For example, when executing 32-bit code on a 64-bit Linux machine,
      the host triple may be 'x86_64-unknown-linux-gnu', while the process
      triple may be 'i386-unknown-linux-gnu'.
      
      This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
      platforms.
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D254
      
      llvm-svn: 172627
      a51c6ed6
    • Evgeniy Stepanov's avatar
      Allow vectors in CreatePointerCast of constants. · 2338264a
      Evgeniy Stepanov authored
      llvm-svn: 172615
      2338264a
    • Evgeniy Stepanov's avatar
      A test for r172535. · a259b26c
      Evgeniy Stepanov authored
      llvm-svn: 172614
      a259b26c
  6. Jan 14, 2013
  7. Jan 12, 2013
  8. Jan 11, 2013
  9. Jan 10, 2013
  10. Jan 07, 2013
  11. Jan 05, 2013
    • Chandler Carruth's avatar
      Rename the unittest from ArrayRecylerTest.cpp to ArrayRecyclerTest.cpp. · 0dba59ae
      Chandler Carruth authored
      Fixes the CMake build. It took me cutting and pasting this before
      I managed to see the missing character. =]
      
      llvm-svn: 171589
      0dba59ae
    • Jakob Stoklund Olesen's avatar
      Add an ArrayRecycler class. · 17a7d22d
      Jakob Stoklund Olesen authored
      This is similar to the existing Recycler allocator, but instead of
      recycling individual objects from a BumpPtrAllocator, arrays of
      different sizes can be allocated.
      
      llvm-svn: 171581
      17a7d22d
    • Chandler Carruth's avatar
      Add time getters to the process interface for requesting the elapsed · ef7f968e
      Chandler Carruth authored
      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
      ef7f968e
  12. Jan 04, 2013
    • Jakob Stoklund Olesen's avatar
      Add an iplist::clearAndLeakNodesUnsafely() function. · 4ccabc1d
      Jakob Stoklund Olesen authored
      The iplist::clear() function can be quite expensive because it traverses
      the entire list, calling deleteNode() and removeNodeFromList() on each
      element. If node destruction and deallocation can be handled some other
      way, clearAndLeakNodesUnsafely() can be used to jettison all nodes
      without bringing them into cache.
      
      The function name is meant to be ominous.
      
      llvm-svn: 171540
      4ccabc1d
    • Nick Kledzik's avatar
      Fix how YAML I/O detects flow sequences. · 11964f2a
      Nick Kledzik authored
      Update test case to verify flow sequence is
      written as a flow sequence.
      
      llvm-svn: 171514
      11964f2a
  13. Jan 02, 2013
  14. Jan 01, 2013
Loading