search for: importfunct

...(or composite) module. During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, with a call chain of thinLTOBackendTask -->CodeGen::runAll (tools/gold/gold-plugin.cpp) --> CodeGen::runLTOPasses ((tools/gold/gold-plugin.cpp) --> FunctionImporter::importFu...

...ot empty. — Mehdi During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, with a call chain of thinLTOBackendTask -->CodeGen::runAll (tools/gold/gold-plugin.cpp) --> CodeGen::runLTOPasses ((tools/gold/gold-plugin.cpp)--> FunctionImporter::importFun...

Hi Dmitry, the direct call patch seems like a good start; however, by falling through to the F->replaceUsesExceptBlockAddr(FDecl) at the bottom of LowerTypeTestsModule::importFunction() I believe it will replace all uses of a function (for a definition outside the TU it's defined in) with the direct function reference instead of just direct calls. Also, I believe the logic for replaceDirectCalls() should be more restrictive, currently it will also rewrite calls where the...

...se below, I get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so the type check ca...

...e test case below, I get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so the type check cannot...

...e below, I get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so the type check ca...

...get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so the type che...

...wing IR for main() on entry to > ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after > I moved this pass down in the pipeline so it’s invoked after inlining. > > > > The declarations for foo() and bar() are read in at the time of module > import, Importer.importFunctions() in lto::thinBackend(). They do not have > type metadata attached to them. > > In lowerTypeTestCall() we check if the pointer in the type test is of a > known type, so we look at bitcast and then select operands. foo and bar in > select are global objects with no type metadata,...

> We could probably tolerate a certain amount of unused jump table entries. However, I just realized that all non-inline imported calls end up going through a jump table entry. Is that correct? In fact it is all calls that go through a function pointer type that is used anywhere in the program for an indirect call, but depending on your program that could be very close to "yes".

...ollowing IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > > > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so the typ...

...r main() on entry to > ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after > I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > The declarations for foo() and bar() are read in at the time of module > import, Importer.importFunctions() in lto::thinBackend(). They do not have > type metadata attached to them. > > > In lowerTypeTestCall() we check if the pointer in the type test is of > a known type, so we look at bitcast and then select operands. foo and bar > in select are global objects with no type metad...

...R for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > > > > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata, so th...

...n entry > to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is > after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > > > The declarations for foo() and bar() are read in at the time of > module import, Importer.importFunctions() in lto::thinBackend(). They do > not have type metadata attached to them. > > > > In lowerTypeTestCall() we check if the pointer in the type test is > of a known type, so we look at bitcast and then select operands. foo and > bar in select are global objects with no type...

...ThinLTO backend invocation of LowerTypeTestsModule::lower(). This > is after I moved this pass down in the pipeline so it’s invoked after > inlining. > > > > > > > > > > The declarations for foo() and bar() are read in at the time of > module import, Importer.importFunctions() in lto::thinBackend(). They do > not have type metadata attached to them. > > > > > In lowerTypeTestCall() we check if the pointer in the type test is > of a known type, so we look at bitcast and then select operands. foo and > bar in select are global objects with no...

...() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > > > > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > > > > > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metadata,...

...ackend invocation of LowerTypeTestsModule::lower(). This > is after I moved this pass down in the pipeline so it’s invoked after > inlining. > > > > > > > > > > > > The declarations for foo() and bar() are read in at the time of > module import, Importer.importFunctions() in lto::thinBackend(). They do > not have type metadata attached to them. > > > > > > In lowerTypeTestCall() we check if the pointer in the type test > is of a known type, so we look at bitcast and then select operands. foo and > bar in select are global objects wit...

...y to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. > > > > > > > > > > > > The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. > > > > > > In lowerTypeTestCall() we check if the pointer in the type test is of a known type, so we look at bitcast and then select operands. foo and bar in select are global objects with no type metad...

...t; > On Apr 30, 2018, at 5:43 PM, Vlad Tsyrklevich <vlad at tsyrklevich.net> > wrote: > > > > Hi Dmitry, the direct call patch seems like a good start; however, by > falling through to the F->replaceUsesExceptBlockAddr(FDecl) at the bottom > of LowerTypeTestsModule::importFunction() I believe it will replace all > uses of a function (for a definition outside the TU it's defined in) with > the direct function reference instead of just direct calls. > > You’re right, it was meant to bail after direct call replacement. > > > Also, I believe the logic...