Skip to content
  1. Feb 01, 2018
    • Jonas Devlieghere's avatar
      [NFC] 'DWARFv5' -> 'DWARF v5' · 197e47f5
      Jonas Devlieghere authored
      llvm-svn: 323950
      197e47f5
    • Yvan Roux's avatar
      Test commit: Fix a comment. · 705e26a2
      Yvan Roux authored
      llvm-svn: 323947
      705e26a2
    • Mikael Holmen's avatar
      [LSR] Don't force bases of foldable formulae to the final type. · 6d06976e
      Mikael Holmen authored
      Summary:
      Before emitting code for scaled registers, we prevent
      SCEVExpander from hoisting any scaled addressing mode
      by emitting all the bases first. However, these bases
      are being forced to the final type, resulting in some
      odd code.
      
      For example, if the type of the base is an integer and
      the final type is a pointer, we will emit an inttoptr
      for the base, a ptrtoint for the scale, and then a
      'reverse' GEP where the GEP pointer is actually the base
      integer and the index is the pointer. It's more intuitive
      to use the pointer as a pointer and the integer as index.
      
      Patch by: Bevin Hansson
      
      Reviewers: atrick, qcolombet, sanjoy
      
      Reviewed By: qcolombet
      
      Subscribers: llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D42103
      
      llvm-svn: 323946
      6d06976e
    • Dean Michael Berris's avatar
      [XRay][compiler-rt+llvm] Update XRay register stashing semantics · cdca0730
      Dean Michael Berris authored
      Summary:
      This change expands the amount of registers stashed by the entry and
      `__xray_CustomEvent` trampolines.
      
      We've found that since the `__xray_CustomEvent` trampoline calls can show up in
      situations where the scratch registers are being used, and since we don't
      typically want to affect the code-gen around the disabled
      `__xray_customevent(...)` intrinsic calls, that we need to save and restore the
      state of even the scratch registers in the handling of these custom events.
      
      Reviewers: pcc, pelikan, dblaikie, eizan, kpw, echristo, chandlerc
      
      Reviewed By: echristo
      
      Subscribers: chandlerc, echristo, hiraditya, davide, dblaikie, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D40894
      
      llvm-svn: 323940
      cdca0730
    • Rafael Espindola's avatar
      [MC] Fix assembler infinite loop on EH table using LEB padding. · 45b12f18
      Rafael Espindola authored
      Fix the infinite loop reported in PR35809. It can occur with GCC-style
      EH table assembly, where the compiler relies on the assembler to
      calculate the offsets in the EH table.
      
      Also see https://sourceware.org/bugzilla/show_bug.cgi?id=4029 for the
      equivalent issue in the GNU assembler.
      
      Patch by Ryan Prichard!
      
      llvm-svn: 323934
      45b12f18
    • Amara Emerson's avatar
      [GlobalOpt] Improve common case efficiency of static global initializer evaluation · 93b0ff20
      Amara Emerson authored
      For very, very large global initializers which can be statically evaluated, the
      code would create vectors of temporary Constants, modifying them in place,
      before committing the resulting Constant aggregate to the global's initializer
      value. This had effectively O(n^2) complexity in the size of the global
      initializer and would cause memory and non-termination issues compiling some
      workloads.
      
      This change performs the static initializer evaluation and creation in batches,
      once for each global in the evaluated IR memory. The existing code is maintained
      as a last resort when the initializers are more complex than simple values in a
      large aggregate. This should theoretically by NFC, no test as the example case
      is massive. The existing test cases pass with this, as well as the llvm test
      suite.
      
      To give an example, consider the following C++ code adapted from the clang
      regression tests:
      struct S {
       int n = 10;
       int m = 2 * n;
       S(int a) : n(a) {}
      };
      
      template<typename T>
      struct U {
       T *r = &q;
       T q = 42;
       U *p = this;
      };
      
      U<S> e;
      
      The global static constructor for 'e' will need to initialize 'r' and 'p' of
      the outer struct, while also initializing the inner 'q' structs 'n' and 'm'
      members. This batch algorithm will simply use general CommitValueTo() method
      to handle the complex nested S struct initialization of 'q', before
      processing the outermost members in a single batch. Using CommitValueTo() to
      handle member in the outer struct is inefficient when the struct/array is
      very large as we end up creating and destroy constant arrays for each
      initialization.
      For the above case, we expect the following IR to be generated:
      
      %struct.U = type { %struct.S*, %struct.S, %struct.U* }
      %struct.S = type { i32, i32 }
      @e = global %struct.U { %struct.S* gep inbounds (%struct.U, %struct.U* @e,
                                                       i64 0, i32 1),
                              %struct.S { i32 42, i32 84 }, %struct.U* @e }
      The %struct.S { i32 42, i32 84 } inner initializer is treated as a complex
      constant expression, while the other two elements of @e are "simple".
      
      Differential Revision: https://reviews.llvm.org/D42612
      
      llvm-svn: 323933
      93b0ff20
    • Matt Arsenault's avatar
      DAG: Fix not truncating when promoting bswap/bitreverse · df0f2507
      Matt Arsenault authored
      These need to convert back to the original type, like any
      other promotion.
      
      llvm-svn: 323932
      df0f2507
  2. Jan 31, 2018
Loading