Skip to content
  1. Nov 20, 2013
    • Chandler Carruth's avatar
      [PM] Add the preservation system to the new pass manager. · c0bfa8c2
      Chandler Carruth authored
      This adds a new set-like type which represents a set of preserved
      analysis passes. The set is managed via the opaque PassT::ID() void*s.
      The expected convenience templates for interacting with specific passes
      are provided. It also supports a symbolic "all" state which is
      represented by an invalid pointer in the set. This state is nicely
      saturating as it comes up often. Finally, it supports intersection which
      is used when finding the set of preserved passes after N different
      transforms.
      
      The pass API is then changed to return the preserved set rather than
      a bool. This is much more self-documenting than the previous system.
      Returning "none" is a conservatively correct solution just like
      returning "true" from todays passes and not marking any passes as
      preserved. Passes can also be dynamically preserved or not throughout
      the run of the pass, and whatever gets returned is the binding state.
      Finally, preserving "all" the passes is allowed for no-op transforms
      that simply can't harm such things.
      
      Finally, the analysis managers are changed to instead of blindly
      invalidating all of the analyses, invalidate those which were not
      preserved. This should rig up all of the basic preservation
      functionality. This also correctly combines the preservation moving up
      from one IR-layer to the another and the preservation aggregation across
      N pass runs. Still to go is incrementally correct invalidation and
      preservation across IR layers incrementally during N pass runs. That
      will wait until we have a device for even exposing analyses across IR
      layers.
      
      While the core of this change is obvious, I'm not happy with the current
      testing, so will improve it to cover at least some of the invalidation
      that I can test easily in a subsequent commit.
      
      llvm-svn: 195241
      c0bfa8c2
    • 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
    • Yuchen Wu's avatar
      llvm-cov: Added file checksum to gcno and gcda files. · babe7491
      Yuchen Wu authored
      Instead of permanently outputting "MVLL" as the file checksum, clang
      will create gcno and gcda checksums by hashing the destination block
      numbers of every arc. This allows for llvm-cov to check if the two gcov
      files are synchronized.
      
      Regenerated the test files so they contain the checksum. Also added
      negative test to ensure error when the checksums don't match.
      
      llvm-svn: 195191
      babe7491
    • 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
    • Filip Pizlo's avatar
      Expose the fence instruction via the C API. · 0d3f7eca
      Filip Pizlo authored
      llvm-svn: 195173
      0d3f7eca
  2. Nov 19, 2013
  3. Nov 18, 2013
    • Paul Robinson's avatar
      The 'optnone' attribute means don't inline anything into this function · dcbe35ba
      Paul Robinson authored
      (except functions marked always_inline).
      Functions with 'optnone' must also have 'noinline' so they don't get
      inlined into any other function.
      
      Based on work by Andrea Di Biagio.
      
      llvm-svn: 195046
      dcbe35ba
    • Alexey Samsonov's avatar
      Revert r194865 and r194874. · 49109a27
      Alexey Samsonov authored
      This change is incorrect. If you delete virtual destructor of both a base class
      and a subclass, then the following code:
        Base *foo = new Child();
        delete foo;
      will not cause the destructor for members of Child class. As a result, I observe
      plently of memory leaks. Notable examples I investigated are:
      ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
      
      llvm-svn: 194997
      49109a27
    • Manman Ren's avatar
      Debug Info Verifier: disable it by default. · 101d3452
      Manman Ren authored
      Debug info verifier is part of the verifier which is a Function Pass.
      Tot currently tries to pull all reachable debug info MDNodes in each function,
      which is too time-consuming. The correct fix seems to be separating debug info
      verification to its own module pass.
      
      I will disable the debug info verifier until a correct fix is found.
      
      For Bill's testing case, enabling debug info verifier increase compile
      time from 11s to 11m.
      
      llvm-svn: 194986
      101d3452
  4. Nov 17, 2013
    • Manman Ren's avatar
      Debug Info: fix typo in function name. · b46e550a
      Manman Ren authored
      llvm-svn: 194975
      b46e550a
    • Manman Ren's avatar
      Debug Info Verifier: fix when to find debug info nodes and when to verify them. · c9e395e9
      Manman Ren authored
      We used to collect debug info MDNodes in doInitialization and verify them in
      doFinalization. That is incorrect since MDNodes can be modified by passes run
      between doInitialization and doFinalization.
      
      To fix the problem, we handle debug info MDNodes that can be reached from a
      function in runOnFunction (i.e we collect those nodes by calling processDeclare,
      processValue and processLocation, and then verify them in runOnFunction).
      
      We handle debug info MDNodes that can be reached from named metadata in
      doFinalization. This is in line with how Verifier handles module-level data
      (they are verified in doFinalization).
      
      rdar://15472296
      
      llvm-svn: 194974
      c9e395e9
    • Manman Ren's avatar
      Debug Info Verifier: enable public functions of Finder to update the type map. · 2085cccf
      Manman Ren authored
      We used to depend on running processModule before the other public functions
      such as processDeclare, processValue and processLocation. We are now relaxing
      the constraint by adding a module argument to the three functions and
      letting the three functions to initialize the type map. This will be used in
      a follow-on patch that collects nodes reachable from a Function.
      
      llvm-svn: 194973
      2085cccf
  5. Nov 16, 2013
  6. Nov 15, 2013
  7. Nov 14, 2013
    • NAKAMURA Takumi's avatar
      IR/GCOV.cpp: Use PRIu64 as format string with uint64_t. · 3241dc42
      NAKAMURA Takumi authored
      llvm-svn: 194693
      3241dc42
    • NAKAMURA Takumi's avatar
      Whitespace. · 3b55196b
      NAKAMURA Takumi authored
      llvm-svn: 194692
      3b55196b
    • Yuchen Wu's avatar
      llvm-cov: Slightly improved error checking. · 7981f5b8
      Yuchen Wu authored
      - readInt() should check all 4 bytes can be read, not just 1.
      - In the event of false data in the gcno file, it was possible to index
        into a non-existent index of SmallVector, causing assertion error.
      
      llvm-svn: 194639
      7981f5b8
    • Yuchen Wu's avatar
      llvm-cov: Removed StringMap holding GCOVLines. · d738beec
      Yuchen Wu authored
      According to the hazy gcov documentation, it appeared to be technically
      possible for lines within a block to belong to different source files.
      However, upon further investigation, gcov does not actually support
      multiple source files for a single block.
      
      This change removes a level of separation between blocks and lines by
      replacing the StringMap of GCOVLines with a SmallVector of ints
      representing line numbers. This also means that the GCOVLines class is
      no longer needed.
      
      This paves the way for supporting the "-a" option, which will output
      block information.
      
      llvm-svn: 194637
      d738beec
    • Yuchen Wu's avatar
      llvm-cov: Replaced asserts with proper error handling. · e28da84c
      Yuchen Wu authored
      Unified the interface for read functions. They all return a boolean
      indicating if the read from file succeeded. Functions that previously
      returned the read value now store it into a variable that is passed in
      by reference instead. Callers will need to check the return value to
      detect if an error occurred.
      
      Also added a new test which ensures that no assertions occur when file
      contains invalid data. llvm-cov should return with error code 1 upon
      failure.
      
      llvm-svn: 194635
      e28da84c
  8. Nov 13, 2013
    • Rafael Espindola's avatar
      Don't call doFinalization from verifyFunction. · 156227ac
      Rafael Espindola authored
      verifyFunction needs to call doInitialization to collect metadata and avoid
      crashing when verifying debug info in a function.
      
      But it should not call doFinalization since that is where the verifier will
      check declarations, variables and aliases, which is not desirable when one
      only wants to verify a function.
      
      A possible cleanup would be to split the class into a ModuleVerifier and
      FunctionVerifier.
      
      Issue reported by Ilia Filippov. Patch by Michael Kruse.
      
      llvm-svn: 194574
      156227ac
    • 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
  9. Nov 11, 2013
  10. Nov 10, 2013
  11. Nov 09, 2013
    • Chandler Carruth's avatar
      Move the old pass manager infrastructure into a legacy namespace and · 7caea415
      Chandler Carruth authored
      give the files a legacy prefix in the right directory. Use forwarding
      headers in the old locations to paper over the name change for most
      clients during the transitional period.
      
      No functionality changed here! This is just clearing some space to
      reduce renaming churn later on with a new system.
      
      Even when the new stuff starts to go in, it is going to be hidden behind
      a flag and off-by-default as it is still WIP and under development.
      
      This patch is specifically designed so that very little out-of-tree code
      has to change. I'm going to work as hard as I can to keep that the case.
      Only direct forward declarations of the PassManager class are impacted
      by this change.
      
      llvm-svn: 194324
      7caea415
  12. Nov 08, 2013
  13. Nov 07, 2013
    • David Majnemer's avatar
      IR: Properly canonicalize PointerType in ConstantExpr GEPs · d3d140da
      David Majnemer authored
      No additional test was needed, Other/constant-fold-gep.ll detects this
      just fine.
      
      llvm-svn: 194221
      d3d140da
    • David Majnemer's avatar
      IR: Do not canonicalize constant GEPs into an out-of-bounds array access · bd4fef4a
      David Majnemer authored
      Summary:
      Consider a GEP of:
      i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0)
      
      If we proceeded to GEP the aforementioned object by 8, would form a GEP of:
      i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8)
      
      Note that we would go through the first array member, causing an
      out-of-bounds accesses.  This is problematic because we might get fooled
      if we are trying to evaluate loads using this GEP, for example, based
      off of an object with a constant initializer where the array is zero.
      
      This fixes PR17732.
      
      Reviewers: nicholas, chandlerc, void
      
      Reviewed By: void
      
      CC: llvm-commits, echristo, void, aemerson
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2093
      
      llvm-svn: 194220
      bd4fef4a
  14. Nov 06, 2013
  15. Nov 05, 2013
Loading