Skip to content
  1. Nov 12, 2009
    • Chris Lattner's avatar
      implement a nice little efficiency hack in the inliner. Since we're now · eb9acbfb
      Chris Lattner authored
      running IPSCCP early, and we run functionattrs interlaced with the inliner,
      we often (particularly for small or noop functions) completely propagate
      all of the information about a call to its call site in IPSSCP (making a call
      dead) and functionattrs is smart enough to realize that the function is
      readonly (because it is interlaced with inliner).
      
      To improve compile time and make the inliner threshold more accurate, realize
      that we don't have to inline dead readonly function calls.  Instead, just 
      delete the call.  This happens all the time for C++ codes, here are some
      counters from opt/llvm-ld counting the number of times calls were deleted vs
      inlined on various apps:
      
      Tramp3d opt:
        5033 inline                - Number of call sites deleted, not inlined
       24596 inline                - Number of functions inlined
      llvm-ld:
        667 inline           - Number of functions deleted because all callers found
        699 inline           - Number of functions inlined
      
      483.xalancbmk opt:
        8096 inline                - Number of call sites deleted, not inlined
       62528 inline                - Number of functions inlined
      llvm-ld:
         217 inline           - Number of allocas merged together
        2158 inline           - Number of functions inlined
      
      471.omnetpp:
        331 inline                - Number of call sites deleted, not inlined
       8981 inline                - Number of functions inlined
      llvm-ld:
        171 inline           - Number of functions deleted because all callers found
        629 inline           - Number of functions inlined
      
      
      Deleting a call is much faster than inlining it, and is insensitive to the
      size of the callee. :)
      
      llvm-svn: 86975
      eb9acbfb
  2. Nov 10, 2009
    • Victor Hernandez's avatar
      Update computeArraySize() to use ComputeMultiple() to determine the array size... · fcc77b1c
      Victor Hernandez authored
      Update computeArraySize() to use ComputeMultiple() to determine the array size associated with a malloc; also extend PerformHeapAllocSRoA() to check if the optimized malloc's arg had its highest bit set, so that it is safe for ComputeMultiple() to look through sext instructions while determining the optimized malloc's array size
      
      llvm-svn: 86676
      fcc77b1c
  3. Nov 07, 2009
    • Victor Hernandez's avatar
      - new SROA mallocs should have the mallocs running-or'ed, not the malloc's bitcast · bde558c5
      Victor Hernandez authored
      - fix ProcessInternalGlobal() debug output
      
      llvm-svn: 86317
      bde558c5
    • Victor Hernandez's avatar
      Re-commit r86077 now that r86290 fixes the 179.art and 175.vpr ARM regressions. · f3db9152
      Victor Hernandez authored
      Here is the original commit message:
      
      This commit updates malloc optimizations to operate on malloc calls that have constant int size arguments.
      
      Update CreateMalloc so that its callers specify the size to allocate:
      MallocInst-autoupgrade users use non-TargetData-computed allocation sizes.
      Optimization uses use TargetData to compute the allocation size.
      
      Now that malloc calls can have constant sizes, update isArrayMallocHelper() to use TargetData to determine the size of the malloced type and the size of malloced arrays.
      Extend getMallocType() to support malloc calls that have non-bitcast uses.
      
      Update OptimizeGlobalAddressOfMalloc() to optimize malloc calls that have non-bitcast uses.  The bitcast use of a malloc call has to be treated specially here because the uses of the bitcast need to be replaced and the bitcast needs to be erased (just like the malloc call) for OptimizeGlobalAddressOfMalloc() to work correctly.
      
      Update PerformHeapAllocSRoA() to optimize malloc calls that have non-bitcast uses.  The bitcast use of the malloc is not handled specially here because ReplaceUsesOfMallocWithGlobal replaces through the bitcast use.
      
      Update OptimizeOnceStoredGlobal() to not care about the malloc calls' bitcast use.
      
      Update all globalopt malloc tests to not rely on autoupgraded-MallocInsts, but instead use explicit malloc calls with correct allocation sizes.
      
      llvm-svn: 86311
      f3db9152
  4. Nov 06, 2009
  5. Nov 05, 2009
    • Dan Gohman's avatar
      Update various Loop optimization passes to cope with the possibility that · a83ac2d9
      Dan Gohman authored
      LoopSimplify form may not be available.
      
      llvm-svn: 86175
      a83ac2d9
    • Victor Hernandez's avatar
      Update CreateMalloc so that its callers specify the size to allocate: · 492ed30a
      Victor Hernandez authored
      MallocInst-autoupgrade users use non-TargetData-computed allocation sizes.
      Optimization uses use TargetData to compute the allocation size.
      
      Now that malloc calls can have constant sizes, update isArrayMallocHelper() to use TargetData to determine the size of the malloced type and the size of malloced arrays.
      Extend getMallocType() to support malloc calls that have non-bitcast uses.
      
      Update OptimizeGlobalAddressOfMalloc() to optimize malloc calls that have non-bitcast uses.  The bitcast use of a malloc call has to be treated specially here because the uses of the bitcast need to be replaced and the bitcast needs to be erased (just like the malloc call) for OptimizeGlobalAddressOfMalloc() to work correctly.
      
      Update PerformHeapAllocSRoA() to optimize malloc calls that have non-bitcast uses.  The bitcast use of the malloc is not handled specially here because ReplaceUsesOfMallocWithGlobal replaces through the bitcast use.
      
      Update OptimizeOnceStoredGlobal() to not care about the malloc calls' bitcast use.
      
      Update all globalopt malloc tests to not rely on autoupgraded-MallocInsts, but instead use explicit malloc calls with correct allocation sizes.
      
      llvm-svn: 86077
      492ed30a
  6. Nov 03, 2009
  7. Nov 01, 2009
  8. Oct 31, 2009
  9. Oct 29, 2009
  10. Oct 28, 2009
  11. Oct 27, 2009
  12. Oct 25, 2009
  13. Oct 24, 2009
  14. Oct 22, 2009
  15. Oct 21, 2009
  16. Oct 19, 2009
  17. Oct 18, 2009
  18. Oct 17, 2009
  19. Oct 15, 2009
    • Victor Hernandez's avatar
      Fix bug where array malloc with unexpected computation of the size argument... · 13020b1f
      Victor Hernandez authored
      Fix bug where array malloc with unexpected computation of the size argument resulted in MallocHelper 
      identifying the malloc as a non-array malloc.  This broke GlobalOpt's optimization of stores of mallocs 
      to global variables.
      
      The fix is to classify malloc's into 3 categories:
      1. non-array mallocs
      2. array mallocs whose array size can be determined
      3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized
      
      getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their 
      malloc optimization if this function returns NULL.
      
      Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in
      isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples.
      
      llvm-svn: 84199
      13020b1f
  20. Oct 13, 2009
  21. Oct 09, 2009
  22. Oct 06, 2009
  23. Oct 05, 2009
  24. Oct 04, 2009
  25. Sep 28, 2009
Loading