Skip to content
  1. Nov 20, 2013
    • Chandler Carruth's avatar
      [PM] Make the function pass manager more regular. · d895e29e
      Chandler Carruth authored
      The FunctionPassManager is now itself a function pass. When run over
      a function, it runs all N of its passes over that function. This is the
      1:N mapping in the pass dimension only. This allows it to be used in
      either a ModulePassManager or potentially some other manager that
      works on IR units which are supersets of Functions.
      
      This commit also adds the obvious adaptor to map from a module pass to
      a function pass, running the function pass across every function in the
      module.
      
      The test has been updated to use this new pattern.
      
      llvm-svn: 195192
      d895e29e
    • Chandler Carruth's avatar
      [PM] Split the analysis manager into a function-specific interface and · ed1ffe01
      Chandler Carruth authored
      a module-specific interface. This is the first of many steps necessary
      to generalize the infrastructure such that we can support both
      a Module-to-Function and Module-to-SCC-to-Function pass manager
      nestings.
      
      After a *lot* of attempts that never worked and didn't even make it to
      a committable state, it became clear that I had gotten the layering
      design of analyses flat out wrong. Four days later, I think I have most
      of the plan for how to correct this, and I'm starting to reshape the
      code into it. This is just a baby step I'm afraid, but starts separating
      the fundamentally distinct concepts of function analysis passes and
      module analysis passes so that in subsequent steps we can effectively
      layer them, and have a consistent design for the eventual SCC layer.
      
      As part of this, I've started some interface changes to make passes more
      regular. The module pass accepts the module in the run method, and some
      of the constructor parameters are gone. I'm still working out exactly
      where constructor parameters vs. method parameters will be used, so
      I expect this to fluctuate a bit.
      
      This actually makes the invalidation less "correct" at this phase,
      because now function passes don't invalidate module analysis passes, but
      that was actually somewhat of a misfeature. It will return in a better
      factored form which can scale to other units of IR. The documentation
      has gotten less verbose and helpful.
      
      llvm-svn: 195189
      ed1ffe01
  2. Nov 19, 2013
  3. Nov 18, 2013
  4. Nov 17, 2013
    • Michael Gottesman's avatar
      [block-freq] Add BlockFrequency::scale that returns a remainder from the... · 4d078a3d
      Michael Gottesman authored
      [block-freq] Add BlockFrequency::scale that returns a remainder from the division and make the private scale in BlockFrequency more performant.
      
      This change is the first in a series of changes improving LLVM's Block
      Frequency propogation implementation to not lose probability mass in
      branchy code when propogating block frequency information from a basic
      block to its successors. This patch is a simple infrastructure
      improvement that does not actually modify the block frequency
      algorithm. The specific changes are:
      
      1. Changes the division algorithm used when scaling block frequencies by
      branch probabilities to a short division algorithm. This gives us the
      remainder for free as well as provides a nice speed boost. When I
      benched the old routine and the new routine on a Sandy Bridge iMac with
      disabled turbo mode performing 8192 iterations on an array of length
      32768, I saw ~600% increase in speed in mean/median performance.
      
      2. Exposes a scale method that returns a remainder. This is important so
      we can ensure that when we scale a block frequency by some branch
      probability BP = N/D, the remainder from the division by D can be
      retrieved and propagated to other children to ensure no probability mass
      is lost (more to come on this).
      
      llvm-svn: 194950
      4d078a3d
    • Chandler Carruth's avatar
      [PM] Completely remove support for explicit 'require' methods on the · a8df4760
      Chandler Carruth authored
      AnalysisManager. All this method did was assert something and we have
      a perfectly good way to trigger that assert from the query path.
      
      llvm-svn: 194947
      a8df4760
  5. Nov 15, 2013
  6. Nov 14, 2013
  7. Nov 13, 2013
    • Rui Ueyama's avatar
      Path: Add tests for existing file magics. · 5e3de7a7
      Rui Ueyama authored
      llvm-svn: 194607
      5e3de7a7
    • Rui Ueyama's avatar
      Whitespace. · 89d1bdb6
      Rui Ueyama authored
      llvm-svn: 194605
      89d1bdb6
    • Chandler Carruth's avatar
      Fix a null pointer dereference when copying a null polymorphic pointer. · ccb19097
      Chandler Carruth authored
      This bug only bit the C++98 build bots because all of the actual uses
      really do move. ;] But not *quite* ready to do the whole C++11 switch
      yet, so clean it up. Also add a unit test that catches this immediately.
      
      llvm-svn: 194548
      ccb19097
    • Chandler Carruth's avatar
      Introduce an AnalysisManager which is like a pass manager but with a lot · 74015a70
      Chandler Carruth authored
      more smarts in it. This is where most of the interesting logic that used
      to live in the implicit-scheduling-hackery of the old pass manager will
      live.
      
      Like the previous commits, note that this is a very early prototype!
      I expect substantial changes before this is ready to use.
      
      The core of the design is the following:
      
      - We have an AnalysisManager which can be used across a series of
        passes over a module.
      - The code setting up a pass pipeline registers the analyses available
        with the manager.
      - Individual transform passes can check than an analysis manager
        provides the analyses they require in order to fail-fast.
      - There is *no* implicit registration or scheduling.
      - Analysis passes are different from other passes: they produce an
        analysis result that is cached and made available via the analysis
        manager.
      - Cached results are invalidated automatically by the pass managers.
      - When a transform pass requests an analysis result, either the analysis
        is run to produce the result or a cached result is provided.
      
      There are a few aspects of this design that I *know* will change in
      subsequent commits:
      - Currently there is no "preservation" system, that needs to be added.
      - All of the analysis management should move up to the analysis library.
      - The analysis management needs to support at least SCC passes. Maybe
        loop passes. Living in the analysis library will facilitate this.
      - Need support for analyses which are *both* module and function passes.
      - Need support for pro-actively running module analyses to have cached
        results within a function pass manager.
      - Need a clear design for "immutable" passes.
      - Need support for requesting cached results when available and not
        re-running the pass even if that would be necessary.
      - Need more thorough testing of all of this infrastructure.
      
      There are other aspects that I view as open questions I'm hoping to
      resolve as I iterate a bit on the infrastructure, and especially as
      I start writing actual passes against this.
      - Should we have separate management layers for function, module, and
        SCC analyses? I think "yes", but I'm not yet ready to switch the code.
        Adding SCC support will likely resolve this definitively.
      - How should the 'require' functionality work? Should *that* be the only
        way to request results to ensure that passes always require things?
      - How should preservation work?
      - Probably some other things I'm forgetting. =]
      
      Look forward to more patches in shorter order now that this is in place.
      
      llvm-svn: 194538
      74015a70
  8. Nov 09, 2013
  9. Nov 07, 2013
  10. Nov 05, 2013
    • Rafael Espindola's avatar
      Simplify ErrorOr. · ca35ffe6
      Rafael Espindola authored
      ErrorOr had quiet a bit of complexity and indirection to be able to hold a user
      type with the error.
      
      That feature is not used anymore. This patch removes it, it will live in svn
      history if we ever need it again.
      
      If we do need it again, IMHO there is one thing that should be done
      differently: Holding extra info in the error is not a property a function also
      returning a value or not. The ability to hold extra info should be in the error
      type and ErrorOr templated over it so that we don't need the funny looking
      ErrorOr<void>.
      
      llvm-svn: 194030
      ca35ffe6
  11. Oct 31, 2013
  12. Oct 30, 2013
    • Rafael Espindola's avatar
      Add calls to doInitialization() and doFinalization() in verifyFunction() · 55fdcff4
      Rafael Espindola authored
      The function verifyFunction() in lib/IR/Verifier.cpp misses some
      calls. It creates a temporary FunctionPassManager that will run a
      single Verifier pass. Unfortunately, FunctionPassManager is no
      PassManager and does not call doInitialization() and doFinalization()
      by itself. Verifier does important tasks in doInitialization() such as
      collecting type information used to check DebugInfo metadata and
      doFinalization() does some additional checks. Therefore these checks
      were missed and debug info couldn't be verified at all, it just
      crashed if the function had some.
      
      verifyFunction() is currently not used in llvm unless -debug option is
      enabled, and in unittests/IR/VerifierTest.cpp
      
      VerifierTest had to be changed to create the function in a module from
      which the type debug info can be collected.
      
      Patch by Michael Kruse.
      
      llvm-svn: 193719
      55fdcff4
    • Rui Ueyama's avatar
      Add {start,end}with_lower methods to StringRef. · 00e24e48
      Rui Ueyama authored
      startswith_lower is ocassionally useful and I think worth adding.
      endwith_lower is added for completeness.
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2041
      
      llvm-svn: 193706
      00e24e48
    • Nuno Lopes's avatar
      make ConstantRange::signExtend() optimal · 1112eca0
      Nuno Lopes authored
      the case [x, INT_MIN) was not handled optimally
      
      llvm-svn: 193694
      1112eca0
  13. Oct 29, 2013
Loading