Skip to content
  1. Jun 25, 2010
  2. Jun 23, 2010
  3. Jun 16, 2010
  4. Jun 04, 2010
  5. Jun 03, 2010
    • Bill Wendling's avatar
      Machine sink could potentially sink instructions into a block where the physical · f82aea63
      Bill Wendling authored
      registers it defines then interfere with an existing preg live range.
      
      For instance, if we had something like these machine instructions:
      
      BB#0
        ... = imul ... EFLAGS<imp-def,dead>
        test ..., EFLAGS<imp-def>
        jcc BB#2 EFLAGS<imp-use>
      
      BB#1
        ... ; fallthrough to BB#2
      
      BB#2
        ... ; No code that defines EFLAGS
        jcc ... EFLAGS<imp-use>
      
      Machine sink will come along, see that imul implicitly defines EFLAGS, but
      because it's "dead", it assumes that it can move imul into BB#2. But when it
      does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and
      messes up the condition code for the jump (and pretty much anything else which
      relies upon it being correct).
      
      The solution is to know which pregs are live going into a basic block. However,
      that information isn't calculated at this point. Nor does the LiveVariables pass
      take into account non-allocatable physical registers. In lieu of this, we do a
      *very* conservative pass through the basic block to determine if a preg is live
      coming out of it.
      
      llvm-svn: 105387
      f82aea63
    • Bill Wendling's avatar
      Compulsive reformating. No functionalitical changes. · 7ee730eb
      Bill Wendling authored
      llvm-svn: 105359
      7ee730eb
  6. May 13, 2010
  7. Apr 16, 2010
    • Jakob Stoklund Olesen's avatar
      Avoid sinking machine instructions into a loop. · cdc3df48
      Jakob Stoklund Olesen authored
      MachineLoopInfo is already available when MachineSinking runs, so the check is
      free.
      
      There is no test case because it would require a critical edge into a loop, and
      CodeGenPrepare splits those. This check is just to be extra careful.
      
      llvm-svn: 101420
      cdc3df48
  8. Apr 13, 2010
    • Jakob Stoklund Olesen's avatar
      Teach MachineSinking to handle easy critical edges. · 20b71e28
      Jakob Stoklund Olesen authored
      Sometimes it is desirable to sink instructions along a critical edge:
      
      x = ...
      if (a && b) ...
      else use(x);
      
      The 'a && b' condition creates a critical edge to the else block, but we still
      want to sink the computation of x into the block. The else block is dominated by
      the parent block, so we are not pushing instructions into new code paths.
      
      llvm-svn: 101165
      20b71e28
  9. Apr 05, 2010
  10. Mar 05, 2010
  11. Mar 02, 2010
  12. Feb 09, 2010
  13. Jan 05, 2010
  14. Oct 25, 2009
  15. Oct 19, 2009
  16. Oct 10, 2009
    • Dan Gohman's avatar
      Factor out LiveIntervalAnalysis' code to determine whether an instruction · 87b02d5b
      Dan Gohman authored
      is trivially rematerializable and integrate it into
      TargetInstrInfo::isTriviallyReMaterializable. This way, all places that
      need to know whether an instruction is rematerializable will get the
      same answer.
      
      This enables the useful parts of the aggressive-remat option by
      default -- using AliasAnalysis to determine whether a memory location
      is invariant, and removes the questionable parts -- rematting operations
      with virtual register inputs that may not be live everywhere.
      
      llvm-svn: 83687
      87b02d5b
  17. Oct 07, 2009
  18. Sep 26, 2009
  19. Aug 23, 2009
  20. Aug 22, 2009
  21. Aug 05, 2009
  22. Aug 01, 2009
  23. Apr 10, 2009
    • Chris Lattner's avatar
      fix two problems with machine sinking: · 30c3de64
      Chris Lattner authored
      1. Sinking would crash when the first instruction of a block was
         sunk due to iterator problems.
      2. Instructions could be sunk to their current block, causing an
         infinite loop.
      
      This fixes PR3968
      
      llvm-svn: 68787
      30c3de64
  24. Feb 15, 2009
  25. Feb 07, 2009
  26. Jan 05, 2009
  27. Oct 03, 2008
  28. Sep 13, 2008
    • Dan Gohman's avatar
      Remove isImm(), isReg(), and friends, in favor of · 38453eeb
      Dan Gohman authored
      isImmediate(), isRegister(), and friends, to avoid confusion
      about having two different names with the same meaning. I'm
      not attached to the longer names, and would be ok with
      changing to the shorter names if others prefer it.
      
      llvm-svn: 56189
      38453eeb
  29. Sep 04, 2008
  30. May 13, 2008
  31. Mar 13, 2008
  32. Feb 10, 2008
  33. Jan 12, 2008
  34. Jan 11, 2008
    • Chris Lattner's avatar
      Simplify the side effect stuff a bit more and make licm/sinking · c8226f32
      Chris Lattner authored
      both work right according to the new flags.
      
      This removes the TII::isReallySideEffectFree predicate, and adds
      TII::isInvariantLoad. 
      
      It removes NeverHasSideEffects+MayHaveSideEffects and adds
      UnmodeledSideEffects as machine instr flags.  Now the clients
      can decide everything they need.
      
      I think isRematerializable can be implemented in terms of the
      flags we have now, though I will let others tackle that.
      
      llvm-svn: 45843
      c8226f32
Loading