>> 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
On Wed, Oct 21, 2009 at 4:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:>> 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 includedNote to self: wait at least 24 hours after soliciting feedback before sending a patch. Anyway, after thinking about it, it should always be safe to override the Module to remove the target data pass, even if it isn't safe to override the Module to substitute different target data. But I still think you should at least have the option to supply target data *without* overriding whatever comes in from the module. An even better question is: does it *ever* make sense to supply a blanket default target data striing? If no target-data option is supplied, wouldn't it be better to default to the target data for the running host? Or would that break existing code and/or tests?
On Oct 22, 2009, at 7:25 AM, Kenneth Uildriks wrote:> On Wed, Oct 21, 2009 at 4:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> 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 > > Note to self: wait at least 24 hours after soliciting feedback before > sending a patch. > > Anyway, after thinking about it, it should always be safe to override > the Module to remove the target data pass, even if it isn't safe to > override the Module to substitute different target data. But I still > think you should at least have the option to supply target data > *without* overriding whatever comes in from the module.In what situations would this be useful? Would it make sense to have opt issue an error if the module and the command-line have incompatible non-empty strings?> An even better question is: does it *ever* make sense to supply a > blanket default target data striing? If no target-data option is > supplied, wouldn't it be better to default to the target data for the > running host? Or would that break existing code and/or tests?It would break existing tests, which currently rely on an empty targetdata string being interpreted as historical sparc settings. But tests can be updated; it's more important to figure out how to make opt useful first. Dan