[LLVMdev] Target data question

[Dan Gohman]

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