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?
On Oct 21, 2009, at 9:31 AM, Kenneth Uildriks wrote:> 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...Yes, that's what's intended.> > 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?I think it's more intuitive to have command-line information override Module information. That's how llc works, for example. Also, is the argument to -defaulttarget a triple, an architecture name, or a targetdata string? If it's a triple, it'd be nice to be consistent with llc and call it -mtriple=. For an architecture name, -march=. If it's a targetdata string, perhaps -targetdata= would be a good name. (As an aside, I wouldn't object to having llc's options renamed to remove the leading 'm', as that seems to have been intended to follow GCC's targeting options, and they aren't the same.) Dan
>> 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? > > I think it's more intuitive to have command-line information override > Module information. That's how llc works, for example. > > Also, is the argument to -defaulttarget a triple, an architecture name, > or a targetdata string? If it's a triple, it'd be nice to be consistent > with llc and call it -mtriple=. For an architecture name, -march=. > If it's a targetdata string, perhaps -targetdata= would be a good name. > > (As an aside, I wouldn't object to having llc's options renamed to > remove the leading 'm', as that seems to have been intended to follow > GCC's targeting options, and they aren't the same.) > > Dan > >The argument to -default-data-layout is a targetdata string. -no-default-data-layout means that no TargetData pass is added unless the module supplies a target data string. llvm-gcc always inserts targetdata. I'm wondering if the code it generates somehow depends on the assumption that 'opt' is taking its target data into account. As in, some of it uses absolute offsets and some of it uses pointer-indexing that gets affected by the targetdata. Anyway, it seemed safer to take the module's targetdata if it was built with targetdata included