[LLVMdev] Target data question

Kenneth Uildriks kennethuil at gmail.com
Thu Oct 22 07:25:31 PDT 2009


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.

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?




More information about the llvm-dev mailing list