Skip to content
  1. Jun 29, 2012
  2. Jun 28, 2012
    • Kostya Serebryany's avatar
      [asan] set a hard limit on the number of instructions instrumented pear each... · c387ca7b
      Kostya Serebryany authored
      [asan] set a hard limit on the number of instructions instrumented pear each BB. This is (hopefully temporary) workaround for PR13225 
      
      llvm-svn: 159344
      c387ca7b
    • Hal Finkel's avatar
      Precompute SCEV pointer analysis prior to instruction fusion in BBVectorize. · 918ca2b8
      Hal Finkel authored
      When both a load/store and its address computation are being vectorized, it can
      happen that the address-computation vectorization destroys SCEV's ability
      to analyize the relative pointer offsets. As a result (like with the aliasing
      analysis info), we need to precompute the necessary information prior to
      instruction fusing.
      
      This was found during stress testing (running through the test suite with a very
      low required chain length); unfortunately, I don't have a small test case.
      
      llvm-svn: 159332
      918ca2b8
    • Hal Finkel's avatar
      Remove a useless check in BBVectorize. · 0873d73c
      Hal Finkel authored
      A shuffle mask will always be a constant, but I did not realize that
      when I originally wrote the code.
      
      llvm-svn: 159331
      0873d73c
    • Hal Finkel's avatar
      Allow BBVectorize to form non-2^n-length vectors. · f2dcb9a9
      Hal Finkel authored
      The original algorithm only used recursive pair fusion of equal-length
      types. This is now extended to allow pairing of any types that share
      the same underlying scalar type. Because we would still generally
      prefer the 2^n-length types, those are formed first. Then a second
      set of iterations form the non-2^n-length types.
      
      Also, a call to SimplifyInstructionsInBlock has been added after each
      pairing iteration. This takes care of DCE (and a few other things)
      that make the following iterations execute somewhat faster. For the
      same reason, some of the simple shuffle-combination cases are now
      handled internally.
      
      There is some additional refactoring work to be done, but I've had
      many requests for this feature, so additional refactoring will come
      soon in future commits (as will additional test cases).
      
      llvm-svn: 159330
      f2dcb9a9
    • Hal Finkel's avatar
      Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. · 74e5225c
      Hal Finkel authored
      Maintaining this kind of checking in different places is dangerous, extending
      Instruction::isSameOperationAs consolidates this logic into one place. Here
      I've added an optional flags parameter and two flags that are important for
      vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes.
      
      llvm-svn: 159329
      74e5225c
    • Bill Wendling's avatar
      Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and · e38859dc
      Bill Wendling authored
      include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
      
      The reasoning is because the DebugInfo module is simply an interface to the
      debug info MDNodes and has nothing to do with analysis.
      
      llvm-svn: 159312
      e38859dc
  3. Jun 27, 2012
    • Matt Beaumont-Gay's avatar
      Revert r159136 due to PR13124. · a5886231
      Matt Beaumont-Gay authored
      Original commit message:
      
      If a constant or a function has linkonce_odr linkage and unnamed_addr, mark it
      hidden. Being linkonce_odr guarantees that it is available in every dso that
      needs it. Being a constant/function with unnamed_addr guarantees that the
      copies don't have to be merged.
      
      llvm-svn: 159272
      a5886231
    • Duncan Sands's avatar
      Some reassociate optimizations create new instructions, which they insert just · 514db117
      Duncan Sands authored
      before the expression root.  Any existing operators that are changed to use one
      of them needs to be moved between it and the expression root, and recursively
      for the operators using that one.  When I rewrote RewriteExprTree I accidentally
      inverted the logic, resulting in the compacting going down from operators to
      operands rather than up from operands to the operators using them, oops.  Fix
      this, resolving PR12963.
      
      llvm-svn: 159265
      514db117
    • Evan Cheng's avatar
      Remove a instcombine transform that (no longer?) makes sense: · 319be53a
      Evan Cheng authored
          // C - zext(bool) -> bool ? C - 1 : C
          if (ZExtInst *ZI = dyn_cast<ZExtInst>(Op1))
            if (ZI->getSrcTy()->isIntegerTy(1))
              return SelectInst::Create(ZI->getOperand(0), SubOne(C), C);
      
      This ends up forming sext i1 instructions that codegen to terrible code. e.g.
      int blah(_Bool x, _Bool y) {
        return (x - y) + 1;
      }
      =>
              movzbl  %dil, %eax
              movzbl  %sil, %ecx
              shll    $31, %ecx
              sarl    $31, %ecx
              leal    1(%rax,%rcx), %eax
              ret
      
      
      Without the rule, llvm now generates:
              movzbl  %sil, %ecx
              movzbl  %dil, %eax
              incl    %eax
              subl    %ecx, %eax
              ret
      
      It also helps with ARM (and pretty much any target that doesn't have a sext i1 :-).
      
      The transformation was done as part of Eli's r75531. He has given the ok to
      remove it.
      
      rdar://11748024
      
      llvm-svn: 159230
      319be53a
  4. Jun 26, 2012
    • Duncan Sands's avatar
      Replacing zero-sized alloca's with a null pointer is too aggressive, instead · 8bc764ae
      Duncan Sands authored
      merge all zero-sized alloca's into one, fixing c43204g from the Ada ACATS
      conformance testsuite.  What happened there was that a variable sized object
      was being allocated on the stack, "alloca i8, i32 %size".  It was then being
      passed to another function, which tested that the address was not null (raising
      an exception if it was) then manipulated %size bytes in it (load and/or store).
      The optimizers cleverly managed to deduce that %size was zero (congratulations
      to them, as it isn't at all obvious), which made the alloca zero size, causing
      the optimizers to replace it with null, which then caused the check mentioned
      above to fail, and the exception to be raised, wrongly.  Note that no loads
      and stores were actually being done to the alloca (the loop that does them is
      executed %size times, i.e. is not executed), only the not-null address check.
      
      llvm-svn: 159202
      8bc764ae
    • Nuno Lopes's avatar
      revert my previous commit (r159173), since as Eli pointed out, it's perfectly... · 31b54a53
      Nuno Lopes authored
      revert my previous commit (r159173), since as Eli pointed out, it's perfectly ok to mark realloc as noalias
      
      llvm-svn: 159175
      31b54a53
    • Nuno Lopes's avatar
      do not set realloc() as NotAlias, since it can return the same pointer. This... · 75eaa72d
      Nuno Lopes authored
      do not set realloc() as NotAlias, since it can return the same pointer. This whole thing should be upgraded to use the MemoryBuiltin interface anyway..
      
      llvm-svn: 159173
      75eaa72d
  5. Jun 25, 2012
  6. Jun 24, 2012
  7. Jun 23, 2012
  8. Jun 22, 2012
  9. Jun 21, 2012
  10. Jun 20, 2012
Loading