[PATCH] D77830: [RFC] Generate more constant iVar Offsets via global LTO analysis

[Alex Borcan via Phabricator via llvm-commits]

alexbdv created this revision.
alexbdv added reviewers: erik.pilkington, pete, rjmccall, ahatanak, dexonsmith.
Herald added subscribers: llvm-commits, dang, jfb, arphaman, steven_wu, hiraditya, inglorion, mgorny.
Herald added a project: LLVM.

Previous work:
This work is extending the work done in D56802 <https://reviews.llvm.org/D56802> which implemented treating iVar Offsets as constant for classes which directly inherit from NSObject. This behavior is possible because the size of NSObject is considered to be constant.
See “FIXME: Can we do this if see a chain of super classes with implementations leading to NSObject?“

Description:
In certain situations we know at compile time what the offset of an instance variable will be. In these situations we can avoid generating a load of the iVar offset from the global offset variable by treating the iVar offset as constant.
We can do this if the entire class layout is defined at compile time and the base class is NSObject (NSObject size is basically ABI and we’re already treating it as such via D56802 <https://reviews.llvm.org/D56802>).
Previously, D56802 <https://reviews.llvm.org/D56802> did this for the most basic case where a class inherits directly from NSObject. 
With this patch, by taking advantage of LTO, we can apply the optimization in all scenarios where the iVar offset can be known at compile-time. We optimize iVar accesses for any class who’s inheritance chain ends in NSObject, even if instance variables are present in the @implementation of base classes.

Implementation details:

- From each compile unit we now export an @interface summary ( this is a newly introduced type of summary ) which contains information about the iVars
- During LLVM IR generation we still do the normal codegen where the iVar offset is not constant (generate a load)
- During LTO initial stage/ThinLTO thinLink stage we read the interface summaries and analyze the information to figure out which classes have compile-time constant iVar offsets and compute these iVar offsets
- During LTO / ThinLTO optimization we recognize load instructions from compile-time-constant iVar offsets and replace the load with a constant variable

Ex:
// Original llvm: 
%ivar1 = load i64,i64* @"OBJC_IVAR_$_Class01.the_iVar_Impl", align 8 // Result = 12 
%add.ptr2 = getelementptr inbounds i8, i8* %0, i64 %ivar1

// Transforms Into:
 %add.ptr2 = getelementptr inbounds i8, i8* %0, i64 12

Note:

- This will have an approx 2% code size reduction - when (benchmarked on a >10MB binary)
- The attached patch is a proof of concept, we will break up this big patch in multiple smaller patches to make review easier
- Will add lit tests as necessary
- Will probably remove the extensive logging that is in this diff




Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77830

Files:
  llvm/include/llvm/Analysis/IVarOptAnalysis.h
  llvm/include/llvm/Analysis/IVarOptLog.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/Transforms/IPO.h
  llvm/include/llvm/Transforms/IPO/IVarDirectAccess.h
  llvm/lib/Analysis/CMakeLists.txt
  llvm/lib/Analysis/IVarOptAnalysis.cpp
  llvm/lib/Analysis/IVarOptLog.cpp
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/CMakeLists.txt
  llvm/lib/Transforms/IPO/IPO.cpp
  llvm/lib/Transforms/IPO/IVarDirectAccess.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D77830.256413.patch
Type: text/x-patch
Size: 123420 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200409/0975dfd1/attachment-0001.bin>