[LLVMdev] Target data question

[Dan Gohman]

On Oct 22, 2009, at 2:22 PM, Kenneth Uildriks wrote:

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

Makes sense.

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

I don't know offhand, though I don't think it's an overwhelming
number. I'd suggest just trying it.

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

Ok. I don't currently have a need for this functionality so I'll
leave it up to you. The main counter-intuitive thing for me is
any option which gets silently ignored when it conflicts with
what's in the module.

Dan