Skip to content
  1. Nov 22, 2013
    • Chandler Carruth's avatar
      [PM] Switch analysis managers to be threaded through the run methods · b3e72199
      Chandler Carruth authored
      rather than the constructors of passes.
      
      This simplifies the APIs of passes significantly and removes an error
      prone pattern where the *same* manager had to be given to every
      different layer. With the new API the analysis managers themselves will
      have to be cross connected with proxy analyses that allow a pass at one
      layer to query for the analysis manager of another layer. The proxy will
      both expose a handle to the other layer's manager and it will provide
      the invalidation hooks to ensure things remain consistent across layers.
      Finally, the outer-most analysis manager has to be passed to the run
      method of the outer-most pass manager. The rest of the propagation is
      automatic.
      
      I've used SFINAE again to allow passes to completely disregard the
      analysis manager if they don't need or want to care. This helps keep
      simple things simple for users of the new pass manager.
      
      Also, the system specifically supports passing a null pointer into the
      outer-most run method if your pass pipeline neither needs nor wants to
      deal with analyses. I find this of dubious utility as while some
      *passes* don't care about analysis, I'm not sure there are any
      real-world users of the pass manager itself that need to avoid even
      creating an analysis manager. But it is easy to support, so there we go.
      
      Finally I renamed the module proxy for the function analysis manager to
      the more verbose but less confusing name of
      FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
      what else to name these things. I'm expecting in the fullness of time to
      potentially have the complete cross product of types at the proxy layer:
      
      {Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
      
      (except for XAnalysisManagerXProxy which doesn't make any sense)
      
      This should make it somewhat easier to do the next phases which is to
      build the upward proxy and get its invalidation correct, as well as to
      make the invalidation within the Module -> Function mapping pass be more
      fine grained so as to invalidate fewer fuction analyses.
      
      After all of the proxy analyses are done and the invalidation working,
      I'll finally be able to start working on the next two fun fronts: how to
      adapt an existing pass to work in both the legacy pass world and the new
      one, and building the SCC, Loop, and Region counterparts. Fun times!
      
      llvm-svn: 195400
      b3e72199
    • Tom Stellard's avatar
      R600: Implement TargetInstrInfo::isLegalToSplitMBBAt() · cd6b0a65
      Tom Stellard authored
      Splitting a basic block will create a new ALU clause, so we need to make
      sure we aren't moving uses of registers that are local to their
      current clause into a new one.
      
      I had a test case for this, but unfortunately unrelated schedule changes
      invalidated it, and I wasn't been able to come up with another one.
      
      NOTE: This is a candidate for the 3.4 branch.
      llvm-svn: 195399
      cd6b0a65
    • Tom Stellard's avatar
      SelectionDAG: Optimize expansion of vec_type = BITCAST scalar_type · 06c67bcb
      Tom Stellard authored
      The legalizer can now do this type of expansion for more
      type combinations without loading and storing to and
      from the stack.
      
      NOTE: This is a candidate for the 3.4 branch.
      llvm-svn: 195398
      06c67bcb
    • Tom Stellard's avatar
      Split SETCC if VSELECT requires splitting too. · 9cbd2c55
      Tom Stellard authored
      This patch is a rewrite of the original patch commited in r194542. Instead of
      relying on the type legalizer to do the splitting for us, we now peform the
      splitting ourselves in the DAG combiner. This is necessary for the case where
      the vector mask is a legal type after promotion and still wouldn't require
      splitting.
      
      Patch by: Juergen Ributzka
      
      NOTE: This is a candidate for the 3.4 branch.
      llvm-svn: 195397
      9cbd2c55
    • Eric Christopher's avatar
      In Dwarf 3 (and Dwarf 2) attributes whose value are offsets into a · 33ff697c
      Eric Christopher authored
      section use the form DW_FORM_data4 whilst in Dwarf 4 and later they
      use the form DW_FORM_sec_offset.
      
      This patch updates the places where such attributes are generated to
      use the appropriate form depending on the Dwarf version. The DIE entries
      affected have the following tags:
      DW_AT_stmt_list, DW_AT_ranges, DW_AT_location, DW_AT_GNU_pubnames,
      DW_AT_GNU_pubtypes, DW_AT_GNU_addr_base, DW_AT_GNU_ranges_base
      
      It also adds a hidden command line option "--dwarf-version=<uint>"
      to llc which allows the version of Dwarf to be generated to override
      what is specified in the metadata; this makes it possible to update
      existing tests to check the debugging information generated for both
      Dwarf 4 (the default) and Dwarf 3 using the same metadata.
      
      Patch (slightly modified) by Keith Walker!
      
      llvm-svn: 195391
      33ff697c
    • Ekaterina Romanova's avatar
      SHLD/SHRD are VectorPath (microcode) instructions known to have poor latency... · d5fa5547
      Ekaterina Romanova authored
      SHLD/SHRD are VectorPath (microcode) instructions known to have poor latency on certain architectures. While generating SHLD/SHRD instructions is acceptable when optimizing for size, optimizing for speed on these platforms should be implemented using alternative sequences of instructions composed of add, adc, shr, shl, or and lea which are directPath instructions. These alternative instructions not only have a lower latency but they also increase the decode bandwidth by allowing simultaneous decoding of a third directPath instruction.
      
      AMD's processors family K7, K8, K10, K12, K15 and K16 are known to have SHLD/SHRD instructions with very poor latency. Optimization guides for these processors recommend using an alternative sequence of instructions. For these AMD's processors, I disabled folding (or (x << c) | (y >> (64 - c))) when we are not optimizing for size.
      
      It might be beneficial to disable this folding for some of the Intel's processors. However, since I couldn't find specific recommendations regarding using SHLD/SHRD instructions on Intel's processors, I haven't disabled this peephole for Intel.
      
      llvm-svn: 195383
      d5fa5547
    • Peter Collingbourne's avatar
      Introduce two command-line flags for the instrumentation pass to control... · 0be79e1a
      Peter Collingbourne authored
      Introduce two command-line flags for the instrumentation pass to control whether the labels of pointers should be ignored in load and store instructions
      
      The new command line flags are -dfsan-ignore-pointer-label-on-store and -dfsan-ignore-pointer-label-on-load. Their default value matches the current labelling scheme.
      
      Additionally, the function __dfsan_union_load is marked as readonly.
      
      Patch by Lorenzo Martignoni!
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2187
      
      llvm-svn: 195382
      0be79e1a
  2. Nov 21, 2013
Loading