[LLVMdev] Target data question

Kenneth Uildriks kennethuil at gmail.com
Thu Oct 22 15:10:05 PDT 2009


> 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 see two approaches so far:

1. Change the tests one by one, having them use the
"no-default-data-layout" flag as they're updated and checked in, then
make "no-default-data-layout" the default when they're all done.

2. Change all the tests to use "default-data-layout" with the Sparc
setting.  Then make "no-default-data-layout" the default.  Update the
tests one-by-one, taking off the "default-data-layout" setting as
they're updated and checked in.  Remove the "default-data-layout"
setting when they're all done, unless someone thinks of a use for it.

If I'm going to attack this, I'll need to get the tests working on my
system first.  (I need to do that anyway to work on the struct-return
thing on my list)




More information about the llvm-dev mailing list