<div dir="auto">I really do think you should just upgrade old layouts to include the address space. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019, 11:00 AM Amy Huang via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">akhuang added a comment.<br>
<br>
In D66843#1669803 <<a href="https://reviews.llvm.org/D66843#1669803" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D66843#1669803</a>>, @rnk wrote:<br>
<br>
> In D66843#1669728 <<a href="https://reviews.llvm.org/D66843#1669728" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D66843#1669728</a>>, @kristina wrote:<br>
><br>
> > If this is only being used for `clang-cl` (or `-fms-compatibility`) mode only, is it possible to limit it to just that rather than it affecting pretty much everything?<br>
><br>
><br>
> We decided we'd rather not do that. There needs to be some way to upgrade the x86 datalayout. It can't be frozen in stone forever.<br>
><br>
> Of course, we need to support the use case of linking old bitcode with new bitcode. Doing that probably requires adding an autoupgrade to replace the old data layout with the new one when loading bitcode. We already have x86-specific intrinsic upgrades in llvm/lib/IR/AutoUpgrade.cpp, so it seems reasonable to add this there, even though it is x86 specific, and remove the X86TargetMachine change.<br>
<br>
<br>
That sounds good; I can work on a patch for that.<br>
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D66843/new/" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D66843/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D66843" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D66843</a><br>
<br>
<br>
<br>
</blockquote></div>