Skip to content
  1. Feb 01, 2018
    • David Green's avatar
      Revert commit rL323951 · 184df0c3
      David Green authored
      Looks like it's causing timeouts out on at least ppc64le
      buildbots.
      
      llvm-svn: 323959
      184df0c3
    • Aleksandar Beserminji's avatar
      [mips] Include EVA instructions in Std2MicroMips mapping tables · a330c208
      Aleksandar Beserminji authored
      This patch includes EVA instructions in the Std2MicroMips mapping
      tables, which is required for direct object emission.
      
      Differential Revision: https://reviews.llvm.org/D41771
      
      llvm-svn: 323958
      a330c208
    • Clement Courbet's avatar
      [AArch64][NFC] Make all ProcResource definitions include their SchedModel. · ea8d07eb
      Clement Courbet authored
      This makes targets ExynosM1,ExynosM3,ThunderX2T99 consistent with all
      other targets.
      
      llvm-svn: 323955
      ea8d07eb
    • Yvan Roux's avatar
      [ARM] Add support for unpredictable MVN instructions. · 490e9e67
      Yvan Roux authored
      This fixes bugzilla 33011
      https://bugs.llvm.org/show_bug.cgi?id=33011
      
      Defines bits {19-16} as zero or unpredictable as specified by the ARM ARM in
      sections A8.8.116 and A8.8.117.
      
      It fixes also the usage of PC register as destination register for MVN
      register-shifted register version as specified in A8.8.117.
      
      Differential Revision: https://reviews.llvm.org/D41905
      
      llvm-svn: 323954
      490e9e67
    • David Green's avatar
      [InstCombine] Allow common type conversions to i8/i16/i32 · e11f0545
      David Green authored
      This, in instcombine, allows conversions to i8/i16/i32 (very
      common cases) even if the resulting type is not legal according
      to the data layout. This can often open up extra combine
      opportunities.
      
      Differential Revision: https://reviews.llvm.org/D42424
      
      llvm-svn: 323951
      e11f0545
    • 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