[LLVMdev] Target data question

[Kenneth Uildriks]

On Thu, Oct 22, 2009 at 3:54 PM, Dan Gohman <gohman at apple.com> wrote:
>> 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?

It is definitely useful to me to tell opt "don't use a target data
string unless the module has one"... then I can feed it modules built
without a target platform, or modules built with the target platform
I'm using, and it'll do the best thing in both cases and break
neither.  "Use this string unless the module has a different one"...
the module would only have a different one if it was compiled by
llvm-gcc or some other front-end specifically targeting some other
platform... and modules specifically targeting different platforms
probably won't get thrown together in the same build, folder, or
process.  So that may not be as useful as I thought.

In short, I definitely want to keep "no-default-data-layout", but not
necessarily "default-data-layout".

>
> Would it make sense to have opt issue an error if the module and the
> command-line have incompatible non-empty strings?

Yes, it would, come to think of it.  If llvm-gcc put a target data
string, it generated code under the assumption that 'opt' would not
use a different target data string.  Breaking that assumption could be
very bad.  (Not having one at all should be safe, since that would
keep opt from messing with existing pointer logic).

> 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.

I was hesitating because fixing the tests and changing opt would have
to be done together in one shot, or else the tests would be broken for
a while.  And that seemed like a daunting task.

I think "no-default-data-layout" all by itself gets us where we need
to be to have opt be useful in just about every case I can think of.
And if production code with pointer operations works with an optimizer
that targets a completely different platform and messes with it's
pointer operations, it's probably very close to breaking mysteriously
at any rate.  So having "no-default-data-layout" be the default would
make production code *more* stable and mainly break those tests, as
far as I can see.  How many tests are we talking, and what's the best
way to attack that problem?

And a force-data-layout with an error if the module has a different
one... that option would find its way into my makefiles as the last
step after an application is linked with the target-independent
standard libraries and is ready to be optimized in a single unit,
whole-program style, with optimizations for the install platform
included without having to make my compiler deal with it.  And if
modules targeting a different platform find their way into my build
process, I definitely want to bring the build to a screeching halt.