Skip to content
  1. Jan 06, 2014
  2. Jan 05, 2014
  3. Jan 04, 2014
    • Alp Toker's avatar
      Add missed cleanup from r198456 · f929e09b
      Alp Toker authored
      All other uses of this macro in LLVM/clang have been moved to the function
      definition so follow suite (and the usage advice) here too for consistency.
      
      llvm-svn: 198516
      f929e09b
    • Craig Topper's avatar
      Tag x86 move to/from debug/control registers with Not64BitMode/In64BitMode.... · bc281ad8
      Craig Topper authored
      Tag x86 move to/from debug/control registers with Not64BitMode/In64BitMode. Remove disassembler hack.
      
      llvm-svn: 198515
      bc281ad8
    • Alp Toker's avatar
      Revert "Fix PR18361: Invalidate LoopDispositions after LoopSimplify hoists things." · 5e9f3265
      Alp Toker authored
      This commit was the source of crasher PR18384:
      
      While deleting: label %for.cond127
      An asserting value handle still pointed to this value!
      UNREACHABLE executed at llvm/lib/IR/Value.cpp:671!
      
      Reverting to get the builders green, feel free to re-land after fixing up.
      (Renato has a handy isolated repro if you need it.)
      
      This reverts commit r198478.
      
      llvm-svn: 198503
      5e9f3265
    • Venkatraman Govindaraju's avatar
    • Venkatraman Govindaraju's avatar
      [SparcV9]: Implement RETURNADDR and FRAMEADDR lowering in SPARC64. · 96ab3bc5
      Venkatraman Govindaraju authored
      Fixes PR18356.
      
      llvm-svn: 198480
      96ab3bc5
    • Andrew Trick's avatar
      Fix PR18361: Invalidate LoopDispositions after LoopSimplify hoists things. · aceac974
      Andrew Trick authored
      getSCEV for an ashr instruction creates an intermediate zext
      expression when it truncates its operand.
      
      The operand is initially inside the loop, so the narrow zext
      expression has a non-loop-invariant loop disposition.
      
      LoopSimplify then runs on an outer loop, hoists the ashr operand, and
      properly invalidate the SCEVs that are mapped to value.
      
      The SCEV expression for the ashr is now an AddRec with the hoisted
      value as the now loop-invariant start value.
      
      The LoopDisposition of this wide value was properly invalidated during
      LoopSimplify.
      
      However, if we later get the ashr SCEV again, we again try to create
      the intermediate zext expression. We get the same SCEV that we did
      earlier, and it is still cached because it was never mapped to a
      Value. When we try to create a new AddRec we abort because we're using
      the old non-loop-invariant LoopDisposition.
      
      I don't have a solution for this other than to clear LoopDisposition
      when LoopSimplify hoists things.
      
      I think the long-term strategy should be to perform LoopSimplify on
      all loops before computing SCEV and before running any loop opts on
      individual loops. It's possible we may want to rerun LoopSimplify on
      individual loops, but it should rarely do anything, so rarely require
      invalidating SCEV.
      
      llvm-svn: 198478
      aceac974
Loading