Skip to content
  1. Feb 12, 2013
  2. Feb 11, 2013
  3. Feb 10, 2013
  4. Feb 09, 2013
  5. Feb 08, 2013
    • Bob Wilson's avatar
      Revert "Add LLVMContext::emitWarning methods and use them. <rdar://problem/12867368>" · bfb44ef9
      Bob Wilson authored
      This reverts r171041. This was a nice idea that didn't work out well.
      Clang warnings need to be associated with warning groups so that they can
      be selectively disabled, promoted to errors, etc. This simplistic patch didn't
      allow for that. Enhancing it to provide some way for the backend to specify
      a front-end warning type seems like overkill for the few uses of this, at
      least for now.
      
      llvm-svn: 174748
      bfb44ef9
    • Hal Finkel's avatar
      DAGCombiner: Constant folding around pre-increment loads/stores · 2581905f
      Hal Finkel authored
      Previously, even when a pre-increment load or store was generated,
      we often needed to keep a copy of the original base register for use
      with other offsets. If all of these offsets are constants (including
      the offset which was combined into the addressing mode), then this is
      clearly unnecessary. This change adjusts these other offsets to use the
      new incremented address.
      
      llvm-svn: 174746
      2581905f
    • Bob Wilson's avatar
      Revert 172027 and 174336. Remove diagnostics about over-aligned stack objects. · 67bbf3aa
      Bob Wilson authored
      Aside from the question of whether we report a warning or an error when we
      can't satisfy a requested stack object alignment, the current implementation
      of this is not good.  We're not providing any source location in the diagnostics
      and the current warning is not connected to any warning group so you can't
      control it.  We could improve the source location somewhat, but we can do a
      much better job if this check is implemented in the front-end, so let's do that
      instead.  <rdar://problem/13127907>
      
      llvm-svn: 174741
      67bbf3aa
    • Arnold Schwaighofer's avatar
      ARM cost model: Address computation in vector mem ops not free · 594fa2dc
      Arnold Schwaighofer authored
      Adds a function to target transform info to query for the cost of address
      computation. The cost model analysis pass now also queries this interface.
      The code in LoopVectorize adds the cost of address computation as part of the
      memory instruction cost calculation. Only there, we know whether the instruction
      will be scalarized or not.
      Increase the penality for inserting in to D registers on swift. This becomes
      necessary because we now always assume that address computation has a cost and
      three is a closer value to the architecture.
      
      radar://13097204
      
      llvm-svn: 174713
      594fa2dc
  6. Feb 07, 2013
  7. Feb 06, 2013
  8. Feb 05, 2013
Loading