Skip to content
  1. Jan 28, 2013
  2. Jan 27, 2013
  3. Jan 25, 2013
  4. Jan 24, 2013
  5. Jan 23, 2013
    • Bill Wendling's avatar
      Add the heuristic to differentiate SSPStrong from SSPRequired. · 7c8f96a9
      Bill Wendling authored
      The requirements of the strong heuristic are:
      
      * A Protector is required for functions which contain an array, regardless of
        type or length.
      
      * A Protector is required for functions which contain a structure/union which
        contains an array, regardless of type or length.  Note, there is no limit to
        the depth of nesting.
      
      * A protector is required when the address of a local variable (i.e., stack
        based variable) is exposed. (E.g., such as through a local whose address is
        taken as part of the RHS of an assignment or a local whose address is taken as
        part of a function argument.)
      
      llvm-svn: 173231
      7c8f96a9
    • Bill Wendling's avatar
      Add the IR attribute 'sspstrong'. · d154e283
      Bill Wendling authored
      SSPStrong applies a heuristic to insert stack protectors in these situations:
      
      * A Protector is required for functions which contain an array, regardless of
        type or length.
      
      * A Protector is required for functions which contain a structure/union which
        contains an array, regardless of type or length.  Note, there is no limit to
        the depth of nesting.
      
      * A protector is required when the address of a local variable (i.e., stack
        based variable) is exposed. (E.g., such as through a local whose address is
        taken as part of the RHS of an assignment or a local whose address is taken as
        part of a function argument.)
      
      This patch implements the SSPString attribute to be equivalent to
      SSPRequired. This will change in a subsequent patch.
      
      llvm-svn: 173230
      d154e283
  6. Jan 22, 2013
    • Tim Northover's avatar
      Make APFloat constructor require explicit semantics. · 29178a34
      Tim Northover authored
      Previously we tried to infer it from the bit width size, with an added
      IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
      value. This default value allowed bugs to creep in, where it was
      inappropriate.
      
      llvm-svn: 173138
      29178a34
  7. Jan 21, 2013
    • Michael Ilseman's avatar
      Introduce a new data structure, the SparseMultiSet, and changes to the MI scheduler to use it. · 3e3194f4
      Michael Ilseman authored
      A SparseMultiSet adds multiset behavior to SparseSet, while retaining SparseSet's desirable properties. Essentially, SparseMultiSet provides multiset behavior by storing its dense data in doubly linked lists that are inlined into the dense vector. This allows it to provide good data locality as well as vector-like constant-time clear() and fast constant time find(), insert(), and erase(). It also allows SparseMultiSet to have a builtin recycler rather than keeping SparseSet's behavior of always swapping upon removal, which allows it to preserve more iterators. It's often a better alternative to a SparseSet of a growable container or vector-of-vector.
      
      llvm-svn: 173064
      3e3194f4
  8. Jan 20, 2013
    • Nadav Rotem's avatar
      · 9450fcff
      Nadav Rotem authored
      Revert 172708.
      
      The optimization handles esoteric cases but adds a lot of complexity both to the X86 backend and to other backends.
      This optimization disables an important canonicalization of chains of SEXT nodes and makes SEXT and ZEXT asymmetrical.
      Disabling the canonicalization of consecutive SEXT nodes into a single node disables other DAG optimizations that assume
      that there is only one SEXT node. The AVX mask optimizations is one example. Additionally this optimization does not update the cost model.
      
      llvm-svn: 172968
      9450fcff
    • David Blaikie's avatar
      The last of PR14471 - emission of constant floats · a39a76ef
      David Blaikie authored
      llvm-svn: 172941
      a39a76ef
  9. Jan 18, 2013
  10. Jan 17, 2013
  11. Jan 16, 2013
  12. Jan 14, 2013
    • Bill Schmidt's avatar
      This patch addresses an incorrect transformation in the DAG combiner. · d006c693
      Bill Schmidt authored
      The included test case is derived from one of the GCC compatibility tests.
      The problem arises after the selection DAG has been converted to type-legalized
      form.  The combiner first sees a 64-bit load that can be converted into a
      pre-increment form.  The original load feeds into a SRL that isolates the
      upper 32 bits of the loaded doubleword.  This looks like an opportunity for
      DAGCombiner::ReduceLoadWidth() to replace the 64-bit load with a 32-bit load.
      
      However, this transformation is not valid, as the replacement load is not
      a pre-increment load.  The pre-increment load produces an extra result,
      which feeds a subsequent add instruction.  The replacement load only has
      one result value, and this value is propagated to all uses of the pre-
      increment load, including the add.  Because the add is looking for the
      second result value as its operand, it ends up attempting to add a constant
      to a token chain, resulting in a crash.
      
      So the patch simply disables this transformation for any load with more than
      two result values.
      
      llvm-svn: 172480
      d006c693
  13. Jan 12, 2013
  14. Jan 11, 2013
Loading