On Tue, Oct 20, 2009 at 12:50 PM, Dan Gohman <gohman at apple.com> wrote:> > On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote: > >> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >>> Unfortunately, yes. See PR4542. Progress has been made recently >>> though -- the optimizers are now ready. The main things left to do >>> is to update the documentation and update the testsuite to account >>> for the change in the meaning of a module without a targetdata string. >>> >>> Dan >>> >>> >> >> So in the near future, the optimizers won't do any target-specific >> transformations in the absence of module target data? > > As near as when someone steps up to do the work :-). I'm not > actively working on this myself right now. > > Dan > >I uncovered a few cases where optimizers still crash when the target data pass isn't registered, and I'll send patches as I can.
If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysis pass can crash the system if the TargetData pass is lurking in the list without being registered. Since we want to be able to run opt without a TargetData pass, this will never do. If TargetData is registered globally, any findAnalysisPass call will find it if there isn't another TargetData pass in the PassManager. Should TargetData now not be considered an ImmutablePass? Should findAnalysisPass include a null check on the getPassInfo of ImmutablePasses?
On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:> If the TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null. So findAnalysisPass > for *any* analysis pass can crash the system if the TargetData pass is > lurking in the list without being registered. > > Since we want to be able to run opt without a TargetData pass, this > will never do. If TargetData is registered globally, any > findAnalysisPass call will find it if there isn't another TargetData > pass in the PassManager. Should TargetData now not be considered an > ImmutablePass? Should findAnalysisPass include a null check on the > getPassInfo of ImmutablePasses? >Never mind, I got confused. Registering a pass doesn't mean that getAnalysisIfAvailable will return it; it still has to be in the pass manager's collection. It just means that PassInfo will be available for it if it's there. I think... Anyway, my present plan of attack is to have a "-defaulttarget" option with "none", "host", or a target string. If -defaulttarget is not specified, the behavior of "opt" will be the same as it is presently. The defaulttarget will be overridden by the Module's target data if it has some. "none" means that no TargetData pass will be added unless the Module supplies target data. "host" uses the running host's TargetData as the default. What do y'all think?