search for: globalstoimport

...at I looked at ended up with aliases > pointing to available_externally functions for instance. > How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. > I’m hesitant about breaking t...

...at I looked at ended up with aliases pointing to available_externally functions for instance. > > How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. So the source module is: @weakalia...

...es. One that I looked at ended up with aliases pointing to available_externally functions for instance. How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. So the source module is: @weakalia...

...ases >> pointing to available_externally functions for instance. >> > > How do these look after IRLinking (in the dest module)? I looked at the > logic in renameModuleForThinLTO and all the conversions to > available_externally are predicated on it being in the provided > GlobalsToImport set. But in FunctionImport.cpp selectCallee() we > specifically prevent importing of aliases that would result in the aliasee > becoming available_externally. Presumably the resulting IRLinked dest > module looks legit, otherwise we would have later verifier failures. > > > So the...

Hey, As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on current trunk) in a few cases. One that I looked at ended up with aliases pointing to available_externally functions for instance. I’m hesitant about breaking the IR verifier like that before calling the IRLinker. The alternative I can see now would

...ked at ended up with aliases pointing to available_externally functions for instance. >> >> How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. > > So the source module is:...

...with aliases pointing to available_externally functions for instance. >>>> >>>> How do these look after IRLinking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. >>> >>> So the so...

....cpp still have a few comments about ThinLTO, namely: /// \brief Link \p Src into the composite. /// /// Passing OverrideSymbols as true will have symbols from Src /// shadow those in the Dest. /// For ThinLTO function importing/exporting the \p ModuleSummaryIndex /// is passed. If \p GlobalsToImport is provided, only the globals that /// are part of the set will be imported from the source module. /// /// Returns true on error. // Don't want to append to global_ctors list, for example, when we // are importing for ThinLTO, otherwise the global ctors and dtors // get executed...

Thanks for the hindsight. I am currently working on a patch/potential fix which introduces a new Linker::ImportIntrinsicGlobalVariables flag. The patch includes a unit test reproducing the problem. Hopefully, that will help getting more feedback. Note that it might take a while before I am allowed to upload the patch since I need approval from Autodesk Legal department. Cheers, Benoit Benoit