[PATCH] D140985: [IR] Support importing modules with invalid data layouts.
Nikita Popov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 11 07:52:55 PST 2023
nikic accepted this revision.
nikic added a comment.
This revision is now accepted and ready to land.
LGTM
================
Comment at: llvm/lib/Bitcode/Reader/BitcodeReader.cpp:4210
+ TentativeDataLayoutStr = llvm::UpgradeDataLayoutString(
+ TentativeDataLayoutStr, TheModule->getTargetTriple());
+
----------------
jsilvanus wrote:
> nikic wrote:
> > High level question: Why is the existing UpgradeDataLayoutString mechanigm not sufficient?
> In the case this is intended for (requiring natural alignment for `i8`), it is true that there is a straightforward fix of a broken data layout string: Just replace `i8`s alignment with natural alignment.
>
> But depending on how `i8` is used in the module, this can break semantics, requiring nontrivial fixup (e.g. adding manual padding). This does not seem to be necessary for DXIL though.
>
> I wanted to avoid auto-upgrade (silently?) breaking a module, and adding the manual padding as part of auto-upgrade seems excessive, at least given that we're not aware of any cases actually requiring it.
>
> On the other hand, letting the user fix the layout string avoids that issue of auto-upgrade breaking a module. If the user is sure that `i8` alignment does not matter, the callback provides the option to fix the DL string.
I see. If this is intended for manual user intervention, then that makes sense.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D140985/new/
https://reviews.llvm.org/D140985
More information about the llvm-commits
mailing list