search for: irobject

...irectory/library into lib/LTO/CodeGen and lib/LTO/Module, containing LTOCodeGenerator and LTOModule, respectively. Only LTOCodeGenerator has a dependence on IPO, removing the circular dependence. Note that libLTO and llvm-lto use LTOModule/LTOCodeGenerator, whereas the gold plugin uses lib/Object/IRObject and lib/Linker directly. The use of LTOModule in the ThinLTO pass is a convenience, but could be avoided by using the IRObject/Linker methods directly if that is preferred. b. Native object wrapper generation support Implement native-object wrapped bitcode writer. The main goal is to more easil...

...en and > lib/LTO/Module, containing LTOCodeGenerator and LTOModule, > respectively. Only LTOCodeGenerator has a dependence on IPO, removing > the circular dependence. > > > Note that libLTO and llvm-lto use LTOModule/LTOCodeGenerator, whereas > the gold plugin uses lib/Object/IRObject and lib/Linker directly. The > use of LTOModule in the ThinLTO pass is a convenience, but could be > avoided by using the IRObject/Linker methods directly if that is > preferred. > > > b. Native object wrapper generation support > > > Implement native-object wrapped b...

...ThinLTO handling would have to be added to your linker (e.g. to invoke the LLVM hooks to write the stage-2 combined function map and either launch the backend processes in parallel or write out a make or other build file). The current support for reading native object wrapped bitcode is baked into IRObjectFile so presumably the Sony linker can handle these native object wrapped bitcode files if it uses libLTO. We would similarly embed the handling of the function index/summary behind an API that can handle either so it is similarly transparent to the linkers. Let me know if there would be additional...

...; to your linker (e.g. to invoke the LLVM hooks to write the stage-2 >>> combined function map and either launch the backend processes in >>> parallel or write out a make or other build file). The current support >>> for reading native object wrapped bitcode is baked into IRObjectFile >>> so presumably the Sony linker can handle these native object wrapped >>> bitcode files if it uses libLTO. We would similarly embed the handling >>> of the function index/summary behind an API that can handle either so >>> it is similarly transparent to th...

...containing LTOCodeGenerator and LTOModule, > > respectively. Only LTOCodeGenerator has a dependence on IPO, removing > > the circular dependence. > > > > > > Note that libLTO and llvm-lto use LTOModule/LTOCodeGenerator, whereas > > the gold plugin uses lib/Object/IRObject and lib/Linker directly. The > > use of LTOModule in the ThinLTO pass is a convenience, but could be > > avoided by using the IRObject/Linker methods directly if that is > > preferred. > > > > > > b. Native object wrapper generation support > > > > &g...

...uld have to be added > to your linker (e.g. to invoke the LLVM hooks to write the stage-2 > combined function map and either launch the backend processes in > parallel or write out a make or other build file). The current support > for reading native object wrapped bitcode is baked into IRObjectFile > so presumably the Sony linker can handle these native object wrapped > bitcode files if it uses libLTO. We would similarly embed the handling > of the function index/summary behind an API that can handle either so > it is similarly transparent to the linkers. Let me know if there...

...dded >> to your linker (e.g. to invoke the LLVM hooks to write the stage-2 >> combined function map and either launch the backend processes in >> parallel or write out a make or other build file). The current support >> for reading native object wrapped bitcode is baked into IRObjectFile >> so presumably the Sony linker can handle these native object wrapped >> bitcode files if it uses libLTO. We would similarly embed the handling >> of the function index/summary behind an API that can handle either so >> it is similarly transparent to the linkers. Let m...

...tor and LTOModule, >> > respectively. Only LTOCodeGenerator has a dependence on IPO, removing >> > the circular dependence. >> > >> > >> > Note that libLTO and llvm-lto use LTOModule/LTOCodeGenerator, whereas >> > the gold plugin uses lib/Object/IRObject and lib/Linker directly. The >> > use of LTOModule in the ThinLTO pass is a convenience, but could be >> > avoided by using the IRObject/Linker methods directly if that is >> > preferred. >> > >> > >> > b. Native object wrapper generation suppor...

...o your linker (e.g. to invoke the LLVM hooks to write the stage-2 > >> combined function map and either launch the backend processes in > >> parallel or write out a make or other build file). The current support > >> for reading native object wrapped bitcode is baked into IRObjectFile > >> so presumably the Sony linker can handle these native object wrapped > >> bitcode files if it uses libLTO. We would similarly embed the handling > >> of the function index/summary behind an API that can handle either so > >> it is similarly transparent t...