In X86Subtarget.h there is a method `getDataLayout' which selects the
data layout depending on the platform, ignoring whatever the user setted
with Module::setDataLayout.
What's the rationale for this?
Data layout is a property of the target, not the program being compiled. If you don't like structure packing etc, use packed structure types.
-Chris
Chris Lattner <clattner@apple.com> writes:
I'm not opposed to having it fail when something semantic (like the alignment of double) is wrong. The hints like the 'native integer types' should not cause it to fail.
-Chris
Chris Lattner <clattner@apple.com> writes:
Chris Lattner <clattner@apple.com> writes:
In X86Subtarget.h there is a method `getDataLayout' which selects the
data layout depending on the platform, ignoring whatever the user setted
with Module::setDataLayout.What's the rationale for this?
Data layout is a property of the target, not the program being
compiled. If you don't like structure packing etc, use packed
structure types.Then, Module::setDataLayout should be removed or make it fail on those
circunstances, shouldn't it?I'm not opposed to having it fail when something semantic (like the
alignment of double) is wrong. The hints like the 'native integer
types' should not cause it to fail.
Then I guess that the information provided by the user through
Module::setDataLayout is used in some places instead of the hard-coded
info provided by X86SubTarget::getDataLayout. This can cause some
trouble as Anton points out on the discussion of bug #7544.
OTOH, I know that if language implementation exchanges data with C/C++,
it must follow certain platform-dependant data layout, but if the
language does not share structs with C/C++ then it is free to align the
data members as it pleases, as long as it does not violate the
constraints imposed by the hardware. It is surprising to see that LLVM
imposes the C/C++ platform's data layout on its users.
I would expect this on X86Subtarget::getDataLayout:
if target layout already setted by user
return it
else
return the platform's C standard
I'm not opposed to having it fail when something semantic (like the
alignment of double) is wrong. The hints like the 'native integer
types' should not cause it to fail.Then I guess that the information provided by the user through
Module::setDataLayout is used in some places instead of the hard-coded
info provided by X86SubTarget::getDataLayout. This can cause some
trouble as Anton points out on the discussion of bug #7544.
Yes, the target data string is intended to allow the optimizers to do target-specific optimizations before code generation. You can leave it empty if you don't want this to happen.
OTOH, I know that if language implementation exchanges data with C/C++,
it must follow certain platform-dependant data layout, but if the
language does not share structs with C/C++ then it is free to align the
data members as it pleases, as long as it does not violate the
constraints imposed by the hardware. It is surprising to see that LLVM
imposes the C/C++ platform's data layout on its users.
It doesn't, just leave it empty.
-Chris
Chris Lattner <clattner@apple.com> writes:
[snip]
OTOH, I know that if language implementation exchanges data with C/C++,
it must follow certain platform-dependant data layout, but if the
language does not share structs with C/C++ then it is free to align the
data members as it pleases, as long as it does not violate the
constraints imposed by the hardware. It is surprising to see that LLVM
imposes the C/C++ platform's data layout on its users.It doesn't, just leave it empty.
I see no way of using a data layout that differs from what
X86SubTarget::getDataLayout provides. Unless I apply a local patch for
that method function, of course.
The point here is that I want to set the data layout my language spec
requires, but LLVM does not allow that because
X86SubTarget::getDataLayout returns whatever GCC uses on each platform.