search for: selectcallee

...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: > > @weakalias = we...

...o 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: @weakalias = weak alias void (...), bitcast (void ()*...

...ing 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 the IR verifier like that before calling the...

...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: @weakalias = weak alias void (...), bitcast (void ()*...

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

...ble_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: > > @weakalias = weak alias void (......

...unctions 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: >>> >>> @...

On Mon, May 1, 2017 at 11:06 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-04-25 12:11 GMT-07:00 Peter Collingbourne <peter at pcc.me.uk>: > >> Hi all, >> >> I've been making a number of changes to the summary representation >> recently, and I wanted to lay out some of my plans so that folks are aware >> of my ultimate