Skip to content
  1. Jan 16, 2015
  2. Jan 15, 2015
    • Filipe Cabecinhas's avatar
      Report fatal errors instead of segfaulting/asserting on a few invalid accesses... · 40139500
      Filipe Cabecinhas authored
      Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files.
      
      Summary:
      Shift an older “invalid file” test to get a consistent naming for these tests.
      
      Bugs found by afl-fuzz
      
      Reviewers: rafael
      
      Subscribers: llvm-commits
      
      Differential Revision: http://reviews.llvm.org/D6945
      
      llvm-svn: 226219
      40139500
    • Lang Hames's avatar
      [Object] Add SF_Exported flag. This flag will be set on all symbols that would · 7e0692b6
      Lang Hames authored
      be exported from a dylib if their containing object file were linked into one.
      
      No test case: No command line tools query this flag, and there are no Object
      unit tests.
      
      llvm-svn: 226217
      7e0692b6
    • Sanjoy Das's avatar
      Revert r226201 (Add a new pass "inductive range check elimination") · 7f62ac8e
      Sanjoy Das authored
      The change used C++11 features not supported by MSVC 2012.  I will fix
      the change to use things supported MSVC 2012 and recommit shortly.
      
      llvm-svn: 226216
      7f62ac8e
    • David Majnemer's avatar
      InductiveRangeCheckElimination: Remove extra ';' · f1f72c9e
      David Majnemer authored
      This silences a GCC warning.
      
      llvm-svn: 226215
      f1f72c9e
    • Andrew Kaylor's avatar
      Fixing pedantic build warnings. · 204096b5
      Andrew Kaylor authored
      llvm-svn: 226214
      204096b5
    • Colin LeMahieu's avatar
      [Hexagon] Fix 226206 by uncommenting required pattern and changing patterns... · c59328e6
      Colin LeMahieu authored
      [Hexagon] Fix 226206 by uncommenting required pattern and changing patterns for simple load-extends.
      
      llvm-svn: 226210
      c59328e6
    • Hal Finkel's avatar
      [PowerPC] Loosen ELFv1 PPC64 func descriptor loads for indirect calls · e2ab0f17
      Hal Finkel authored
      Function pointers under PPC64 ELFv1 (which is used on PPC64/Linux on the
      POWER7, A2 and earlier cores) are really pointers to a function descriptor, a
      structure with three pointers: the actual pointer to the code to which to jump,
      the pointer to the TOC needed by the callee, and an environment pointer. We
      used to chain these loads, and make them opaque to the rest of the optimizer,
      so that they'd always occur directly before the call. This is not necessary,
      and in fact, highly suboptimal on embedded cores. Once the function pointer is
      known, the loads can be performed ahead of time; in fact, they can be hoisted
      out of loops.
      
      Now these function descriptors are almost always generated by the linker, and
      thus the contents of the descriptors are invariant. As a result, by default,
      we'll mark the associated loads as invariant (allowing them to be hoisted out
      of loops). I've added a target feature to turn this off, however, just in case
      someone needs that option (constructing an on-stack descriptor, casting it to a
      function pointer, and then calling it cannot be well-defined C/C++ code, but I
      can imagine some JIT-compilation system doing so).
      
      Consider this simple test:
        $ cat call.c
      
        typedef void (*fp)();
        void bar(fp x) {
          for (int i = 0; i < 1600000000; ++i)
            x();
        }
      
        $ cat main.c
      
        typedef void (*fp)();
        void bar(fp x);
        void foo() {}
        int main() {
          bar(foo);
        }
      
      On the PPC A2 (the BG/Q supercomputer), marking the function-descriptor loads
      as invariant brings the execution time down to ~8 seconds from ~32 seconds with
      the loads in the loop.
      
      The difference on the POWER7 is smaller. Compiling with:
      
        gcc -std=c99 -O3 -mcpu=native call.c main.c : ~6 seconds [this is 4.8.2]
      
        clang -O3 -mcpu=native call.c main.c : ~5.3 seconds
      
        clang -O3 -mcpu=native call.c main.c -mno-invariant-function-descriptors : ~4 seconds
        (looks like we'd benefit from additional loop unrolling here, as a first
         guess, because this is faster with the extra loads)
      
      The -mno-invariant-function-descriptors will be added to Clang shortly.
      
      llvm-svn: 226207
      e2ab0f17
    • Colin LeMahieu's avatar
    • Sanjoy Das's avatar
      Add a new pass "inductive range check elimination" · 7059e295
      Sanjoy Das authored
      IRCE eliminates range checks of the form
      
        0 <= A * I + B < Length
      
      by splitting a loop's iteration space into three segments in a way
      that the check is completely redundant in the middle segment.  As an
      example, IRCE will convert
      
        len = < known positive >
        for (i = 0; i < n; i++) {
          if (0 <= i && i < len) {
            do_something();
          } else {
            throw_out_of_bounds();
          }
        }
      
      to
      
        len = < known positive >
        limit = smin(n, len)
        // no first segment
        for (i = 0; i < limit; i++) {
          if (0 <= i && i < len) { // this check is fully redundant
            do_something();
          } else {
            throw_out_of_bounds();
          }
        }
        for (i = limit; i < n; i++) {
          if (0 <= i && i < len) {
            do_something();
          } else {
            throw_out_of_bounds();
          }
        }
      
      
      IRCE can deal with multiple range checks in the same loop (it takes
      the intersection of the ranges that will make each of them redundant
      individually).
      
      Currently IRCE does not do any profitability analysis.  That is a
      TODO.
      
      Please note that the status of this pass is *experimental*, and it is
      not part of any default pass pipeline.  Having said that, I will love
      to get feedback and general input from people interested in trying
      this out.
      
      Differential Revision: http://reviews.llvm.org/D6693
      
      llvm-svn: 226201
      7059e295
    • Hal Finkel's avatar
      Revert "r226086 - Revert "r226071 - [RegisterCoalescer] Remove copies to reserved registers"" · 5ef58eb8
      Hal Finkel authored
      Reapply r226071 with fixes. Two fixes:
      
       1. We need to manually remove the old and create the new 'deaf defs'
          associated with physical register definitions when we move the definition of
          the physical register from the copy point to the point of the original vreg def.
      
          This problem was picked up by the machinstr verifier, and could trigger a
          verification failure on test/CodeGen/X86/2009-02-12-DebugInfoVLA.ll, so I've
          turned on the verifier in the tests.
      
       2. When moving the def point of the phys reg up, we need to make sure that it
          is neither defined nor read in between the two instructions. We don't, however,
          extend the live ranges of phys reg defs to cover uses, so just checking for
          live-range overlap between the pair interval and the phys reg aliases won't
          pick up reads. As a result, we manually iterate over the range and check for
          reads.
      
          A test soon to be committed to the PowerPC backend will test this change.
      
      Original commit message:
      
      [RegisterCoalescer] Remove copies to reserved registers
      
      This allows the RegisterCoalescer to join "non-flipped" range pairs with a
      physical destination register -- which allows the RegisterCoalescer to remove
      copies like this:
      
      <vreg> = something (maybe a load, for example)
      ... (things that don't use PHYSREG)
      PHYSREG = COPY <vreg>
      
      (with all of the restrictions normally applied by the RegisterCoalescer: having
      compatible register classes, etc. )
      
      Previously, the RegisterCoalescer handled only the opposite case (copying
      *from* a physical register). I don't handle the problem fully here, but try to
      get the common case where there is only one use of <vreg> (the COPY).
      
      An upcoming commit to the PowerPC backend will make this pattern much more
      common on PPC64/ELF systems.
      
      llvm-svn: 226200
      5ef58eb8
    • Philip Reames's avatar
      Style cleanup of old gc.root lowering code · 66c9fb0d
      Philip Reames authored
      Use static functions for helpers rather than static member functions.  a) this changes the linking (minor at best), and b) this makes it obvious no object state is involved.
      
      llvm-svn: 226198
      66c9fb0d
    • Matt Arsenault's avatar
      R600/SI: Improve fpext / fptrunc test coverage · 59b09ab9
      Matt Arsenault authored
      llvm-svn: 226197
      59b09ab9
    • Philip Reames's avatar
      clang-format GCStrategy.cpp & GCRootLowering.cpp (NFC) · b8714416
      Philip Reames authored
      llvm-svn: 226196
      b8714416
    • Philip Reames's avatar
      Split GCStrategy.cpp into two files (NFC) · f27f3738
      Philip Reames authored
      This preparation for an update to http://reviews.llvm.org/D6811.  GCStrategy.cpp will hopefully be moving into IR/, where as the lowering logic needs to stay in CodeGen/
      
      llvm-svn: 226195
      f27f3738
    • Colin LeMahieu's avatar
      [Hexagon] Removing old versions of vsplice, valign, cl0, ct0 and updating... · 538b8581
      Colin LeMahieu authored
      [Hexagon] Removing old versions of vsplice, valign, cl0, ct0 and updating references to new versions.
      
      llvm-svn: 226194
      538b8581
    • Marek Olsak's avatar
      R600/SI: Unify VOP2 instructions which are VOP3-only on VI · f0b130ac
      Marek Olsak authored
      This removes some duplicated classes and definitions.
      
      These instructions are defined:
        _e32 // pseudo
        _e32_si
        _e64 // pseudo
        _e64_si
        _e64_vi
      
      llvm-svn: 226191
      f0b130ac
    • Marek Olsak's avatar
      c5368505
Loading