Skip to content
  1. Jun 24, 2010
  2. Jun 23, 2010
  3. Jun 22, 2010
  4. Jun 21, 2010
  5. Jun 19, 2010
  6. Jun 18, 2010
    • Evan Cheng's avatar
      Teach iff-converter to properly count # of dups. It was not skipping over... · c0e0d85b
      Evan Cheng authored
      Teach iff-converter to properly count # of dups. It was not skipping over dbg_value's which resulted in non-duplicated instructions being deleted. rdar://8104384.
      
      llvm-svn: 106323
      c0e0d85b
    • Jim Grosbach's avatar
      Add Expand-to-libcall support for additional atomics. This covers the usual · d64dfc15
      Jim Grosbach authored
      entries used by llvm-gcc. *_[U]MIN and such can be added later if needed.
      
      This enables the front ends to simplify handling of the atomic intrinsics by
      removing the target-specific decision about which targets can handle the
      intrinsics.
      
      llvm-svn: 106321
      d64dfc15
    • Dan Gohman's avatar
      Don't leak RegClass2VRegMap, which is now a new[] array instead of a · e5457c27
      Dan Gohman authored
      std::vector.
      
      llvm-svn: 106298
      e5457c27
    • Dan Gohman's avatar
      Start TargetRegisterClass indices at 0 instead of 1, so that · 882bb298
      Dan Gohman authored
      MachineRegisterInfo doesn't have to confusingly allocate an extra
      entry.
      
      llvm-svn: 106296
      882bb298
    • Bob Wilson's avatar
      Fix PR7372: Conditional branches (at least on ARM) are treated as predicated, · f82c8fcc
      Bob Wilson authored
      so when IfConverter::CopyAndPredicateBlock checks to see if it should ignore
      an instruction because it is a branch, it should not check if the branch is
      predicated.
      
      This case (when IgnoreBr is true) is only relevant from IfConvertTriangle,
      where new branches are inserted after the block has been copied and predicated.
      If the original branch is not removed, we end up with multiple conditional
      branches (possibly conflicting) at the end of the block.  Aside from any
      immediate errors resulting from that, this confuses the AnalyzeBranch functions
      so that the branches are not analyzable.  That in turn causes the IfConverter to
      think that the "Simple" pattern can be applied, and things go downhill fast
      because the "Simple" pattern does _not_ apply if the block can fall through.
      
      This is pretty fragile.  If there are other degenerate cases where AnalyzeBranch
      fails, but where the block may still fall through, the IfConverter should not
      perform its "Simple" if-conversion.  But, I don't know how to do that with the
      current AnalyzeBranch interface, so for now, the best thing seems to be to
      avoid creating branches that AnalyzeBranch cannot handle.
      
      Evan, please review!
      
      llvm-svn: 106291
      f82c8fcc
Loading