Skip to content
  1. May 28, 2013
  2. May 27, 2013
    • Preston Gurd's avatar
      Convert sqrt functions into sqrt instructions when -ffast-math is in effect. · 048f99de
      Preston Gurd authored
      When -ffast-math is in effect (on Linux, at least), clang defines
      __FINITE_MATH_ONLY__ > 0 when including <math.h>. This causes the
      preprocessor to include <bits/math-finite.h>, which renames the sqrt functions.
      For instance, "sqrt" is renamed as "__sqrt_finite". 
      
      This patch adds the 3 new names in such a way that they will be treated
      as equivalent to their respective original names.
      
      llvm-svn: 182739
      048f99de
  3. May 26, 2013
  4. May 25, 2013
  5. May 23, 2013
  6. May 22, 2013
  7. May 21, 2013
  8. May 20, 2013
  9. May 18, 2013
  10. May 17, 2013
  11. May 16, 2013
  12. May 15, 2013
    • Hal Finkel's avatar
      Fix legalization of SETCC with promoted integer intrinsics · 1f6a7f53
      Hal Finkel authored
      If the input operands to SETCC are promoted, we need to make sure that we
      either use the promoted form of both operands (or neither); a mixture is not
      allowed. This can happen, for example, if a target has a custom promoted
      i1-returning intrinsic (where i1 is not a legal type). In this case, we need to
      use the promoted form of both operands.
      
      This change only augments the behavior of the existing logic in the case where
      the input types (which may or may not have already been legalized) disagree,
      and should not affect existing target code because this case would otherwise
      cause an assert in the SETCC operand promotion code.
      
      This will be covered by (essentially all of the) tests for the new PPCCTRLoops
      infrastructure.
      
      llvm-svn: 181926
      1f6a7f53
    • Derek Schuff's avatar
      Fix miscompile due to StackColoring incorrectly merging stack slots (PR15707) · d2c42d76
      Derek Schuff authored
      IR optimisation passes can result in a basic block that contains:
      
        llvm.lifetime.start(%buf)
        ...
        llvm.lifetime.end(%buf)
        ...
        llvm.lifetime.start(%buf)
      
      Before this change, calculateLiveIntervals() was ignoring the second
      lifetime.start() and was regarding %buf as being dead from the
      lifetime.end() through to the end of the basic block.  This can cause
      StackColoring to incorrectly merge %buf with another stack slot.
      
      Fix by removing the incorrect Starts[pos].isValid() and
      Finishes[pos].isValid() checks.
      
      Just doing:
            Starts[pos] = Indexes->getMBBStartIdx(MBB);
            Finishes[pos] = Indexes->getMBBEndIdx(MBB);
      unconditionally would be enough to fix the bug, but it causes some
      test failures due to stack slots not being merged when they were
      before.  So, in order to keep the existing tests passing, treat LiveIn
      and LiveOut separately rather than approximating the live ranges by
      merging LiveIn and LiveOut.
      
      This fixes PR15707.
      Patch by Mark Seaborn.
      
      llvm-svn: 181922
      d2c42d76
    • David Blaikie's avatar
      Use only explicit bool conversion operators · 041f1aa3
      David Blaikie authored
      BitVector/SmallBitVector::reference::operator bool remain implicit since
      they model more exactly a bool, rather than something else that can be
      boolean tested.
      
      The most common (non-buggy) case are where such objects are used as
      return expressions in bool-returning functions or as boolean function
      arguments. In those cases I've used (& added if necessary) a named
      function to provide the equivalent (or sometimes negative, depending on
      convenient wording) test.
      
      One behavior change (YAMLParser) was made, though no test case is
      included as I'm not sure how to reach that code path. Essentially any
      comparison of llvm::yaml::document_iterators would be invalid if neither
      iterator was at the end.
      
      This helped uncover a couple of bugs in Clang - test cases provided for
      those in a separate commit along with similar changes to `operator bool`
      instances in Clang.
      
      llvm-svn: 181868
      041f1aa3
  13. May 14, 2013
  14. May 13, 2013
  15. May 11, 2013
Loading