Chris Lattner <clattner at apple.com> writes:> On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >>> >>>> 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
On Jul 5, 2010, at 10:24 AM, Óscar Fuentes wrote:>> 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 at 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.