Hi all, The Language Reference says: "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. Instead, if specified, the target data layout is required to match what the ultimate code generator expects. This string is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. If you would like to generate IR that does not embed this target-specific detail into the IR, then you don’t have to specify the string. This will disable some optimizations that require precise layout information, but this also prevents those optimizations from introducing target specificity into the IR.” I understand from this that the DataLayout present in the Module *must* match the DataLayout that the Target will use. There is no runtime check to enforce this at that time. My impression is that I can set the DataLayout on the Module to be big-endian and run the optimizer and the X86 backend. The IR-level passes will use the DataLayout supplied with the Module and the backend code will silently use the TargetMachine one. Should we enforce that the DataLayout attached to the Module matches the one expected by the Target? Thanks, Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/9de5dfa4/attachment.html>
> On Mar 10, 2015, at 5:19 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi all, > > The Language Reference says: > > "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. > Instead, if specified, the target data layout is required to match what the ultimate code generator expects. This string is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. If you would like to generate IR that does not embed this target-specific detail into the IR, then you don’t have to specify the string. This will disable some optimizations that require precise layout information, but this also prevents those optimizations from introducing target specificity into the IR.” > I understand from this that the DataLayout present in the Module *must* match the DataLayout that the Target will use. > There is no runtime check to enforce this at that time. > My impression is that I can set the DataLayout on the Module to be big-endian and run the optimizer and the X86 backend. > The IR-level passes will use the DataLayout supplied with the Module and the backend code will silently use the TargetMachine one. > Should we enforce that the DataLayout attached to the Module matches the one expected by the Target?Yes. :-) —Owen
On Tue, Mar 10, 2015, 5:19 PM Mehdi Amini <mehdi.amini at apple.com> wrote: Hi all, The Language Reference says: "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. Instead, if specified, the target data layout is required to match what the ultimate *code generator* expects. This string is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. If you would like to generate IR that does not embed this target-specific detail into the IR, then you don’t have to specify the string. This will disable some optimizations that require precise layout information, but this also prevents those optimizations from introducing target specificity into the IR.” I understand from this that the DataLayout present in the Module *must* match the DataLayout that the Target will use. There is no runtime check to enforce this at that time. My impression is that I can set the DataLayout on the Module to be big-endian and run the optimizer and the X86 backend. The IR-level passes will use the DataLayout supplied with the Module and the backend code will silently use the TargetMachine one. Should we enforce that the DataLayout attached to the Module matches the one expected by the Target? Definitely. That said clang does this in asserts mode. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/53a9cd61/attachment.html>
> On Mar 10, 2015, at 8:50 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Tue, Mar 10, 2015, 5:19 PM Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > > Hi all, > > The Language Reference says: > > "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. > > Instead, if specified, the target data layout is required to match what the ultimate code generator expects. This string is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. If you would like to generate IR that does not embed this target-specific detail into the IR, then you don’t have to specify the string. This will disable some optimizations that require precise layout information, but this also prevents those optimizations from introducing target specificity into the IR.” > > I understand from this that the DataLayout present in the Module *must* match the DataLayout that the Target will use. > > There is no runtime check to enforce this at that time. > > My impression is that I can set the DataLayout on the Module to be big-endian and run the optimizer and the X86 backend. > > The IR-level passes will use the DataLayout supplied with the Module and the backend code will silently use the TargetMachine one. > > Should we enforce that the DataLayout attached to the Module matches the one expected by the Target? > > > Definitely. That said clang does this in asserts mode. >Can you be more specific? From what I see, clang (for an IR file only of course) will match the triple, but not the DataLayout (or I haven’t found where): if (TheModule->getTargetTriple() != TargetOpts.Triple) { CI.getDiagnostics().Report(SourceLocation(), diag::warn_fe_override_module) << TargetOpts.Triple; TheModule->setTargetTriple(TargetOpts.Triple); } Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/fc6126c2/attachment.html>