Skip to content
  1. Jun 19, 2010
  2. 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
    • 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
    • Stuart Hastings's avatar
      Add a DebugLoc parameter to TargetInstrInfo::InsertBranch(). This · 0125b641
      Stuart Hastings authored
      addresses a longstanding deficiency noted in many FIXMEs scattered
      across all the targets.
      
      This effectively moves the problem up one level, replacing eleven
      FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path
      through FastISel where we actually supply a DebugLoc, fixing Radar
      7421831.
      
      llvm-svn: 106243
      0125b641
  3. Jun 16, 2010
  4. Jun 15, 2010
  5. Jun 14, 2010
  6. Jun 07, 2010
  7. Jun 05, 2010
  8. Jan 04, 2010
    • David Greene's avatar
      · 72e47cd6
      David Greene authored
      Change errs() to dbgs().
      
      llvm-svn: 92520
      72e47cd6
  9. Nov 21, 2009
  10. Oct 28, 2009
    • Bob Wilson's avatar
      Revert r85346 change to control tail merging by CodeGenOpt::Level. · 97b93126
      Bob Wilson authored
      I'm going to redo this using the OptimizeForSize function attribute.
      
      llvm-svn: 85426
      97b93126
    • Bob Wilson's avatar
      Record CodeGen optimization level in the BranchFolding pass so that we can · 9693f9d4
      Bob Wilson authored
      use it to control tail merging when there is a tradeoff between performance
      and code size.  When there is only 1 instruction in the common tail, we have
      been merging.  That can be good for code size but is a definite loss for
      performance.  Now we will avoid tail merging in that case when the
      optimization level is "Aggressive", i.e., "-O3".  Radar 7338114.
      
      Since the IfConversion pass invokes BranchFolding, it too needs to know
      the optimization level.  Note that I removed the RegisterPass instantiation
      for IfConversion because it required a default constructor.  If someone
      wants to keep that for some reason, we can add a default constructor with
      a hard-wired optimization level.
      
      llvm-svn: 85346
      9693f9d4
  11. Oct 25, 2009
  12. Sep 04, 2009
  13. Aug 23, 2009
  14. Aug 22, 2009
  15. Jul 25, 2009
    • Daniel Dunbar's avatar
      More migration to raw_ostream, the water has dried up around the iostream hole. · 0dd5e1ed
      Daniel Dunbar authored
       - Some clients which used DOUT have moved to DEBUG. We are deprecating the
         "magic" DOUT behavior which avoided calling printing functions when the
         statement was disabled. In addition to being unnecessary magic, it had the
         downside of leaving code in -Asserts builds, and of hiding potentially
         unnecessary computations.
      
      llvm-svn: 77019
      0dd5e1ed
  16. Jul 14, 2009
  17. Jul 12, 2009
  18. Jul 11, 2009
  19. Jun 25, 2009
  20. Jun 15, 2009
  21. May 14, 2009
  22. May 05, 2009
  23. Nov 04, 2008
  24. Oct 21, 2008
    • Dan Gohman's avatar
      Optimized FCMP_OEQ and FCMP_UNE for x86. · 97d95d6d
      Dan Gohman authored
      Where previously LLVM might emit code like this:
      
              ucomisd %xmm1, %xmm0
              setne   %al
              setp    %cl
              orb     %al, %cl
              jne     .LBB4_2
      
      it now emits this:
      
              ucomisd %xmm1, %xmm0
              jne     .LBB4_2
              jp      .LBB4_2
      
      It has fewer instructions and uses fewer registers, but it does
      have more branches. And in the case that this code is followed by
      a non-fallthrough edge, it may be followed by a jmp instruction,
      resulting in three branch instructions in sequence. Some effort
      is made to avoid this situation.
      
      To achieve this, X86ISelLowering.cpp now recognizes FCMP_OEQ and
      FCMP_UNE in lowered form, and replace them with code that emits
      two branches, except in the case where it would require converting
      a fall-through edge to an explicit branch.
      
      Also, X86InstrInfo.cpp's branch analysis and transform code now
      knows now to handle blocks with multiple conditional branches. It
      uses loops instead of having fixed checks for up to two
      instructions. It can now analyze and transform code generated
      from FCMP_OEQ and FCMP_UNE.
      
      llvm-svn: 57873
      97d95d6d
  25. Sep 04, 2008
  26. Aug 22, 2008
  27. Aug 15, 2008
  28. Jul 08, 2008
    • Dan Gohman's avatar
      Pool-allocation for MachineInstrs, MachineBasicBlocks, and · 3b460303
      Dan Gohman authored
      MachineMemOperands. The pools are owned by MachineFunctions.
      
      This drastically reduces the number of calls to malloc/free made
      during the "Emit" phase of scheduling, as well as later phases
      in CodeGen. Combined with other changes, this speeds up the
      "instruction selection" phase of CodeGen by 10% in some cases.
      
      llvm-svn: 53212
      3b460303
Loading