<div dir="rtl"><div dir="ltr">They come in three. The third DataLayout is allocated in CodeGeneratorImpl::Initialize() and used in CodeGenModule::getDataLayout(). It may be possible to simply redirect it to the module DataLayout as well, I had not tested it. The duplication wastes cpu cycles as StructLayouts are re-computed repeatedly in the different DataLayout for different clients.</div><div dir="ltr"><br></div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-06-25 15:57 GMT+03:00 Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Long term I think we should keep only the one in the module.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 24 June 2015 at 14:42, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
> Hi all,<br>
><br>
> We have multiple DataLayout object in flight during a compilation: at least the one owned by the Module and the one owned by the TargetMachine.<br>
> There are two issues:<br>
> 1) What if they differ? I guess we could assert at the beginning of CodeGen.<br>
> 2) The DataLayout has internal mutable state (a cache of StructLayout).<br>
><br>
> The latter is my current concern: the cache in DataLayout is based on Type pointer which means that is has to be Context specific.<br>
> This is fine with the DataLayout attached to the Module but not with the TargetMachine.<br>
> The cache could live in the Context, but it is also DataLayout specific so it wouldn’t be a good fit either.<br>
><br>
> I considered modifying the cache in the DataLayout to invalidate itself when queried with a new Context, however it wouldn’t work in a multi-threaded environment (or the query would have to be behind a Mutex).<br>
><br>
> Another option is to remove the DataLayout from the TargetMachine, I tried it and it seems possible but awkward as well in some places where the DataLayout has to be supplied externally because TargetLoweringXX would not have it.<br>
><br>
> Finally the TargetMachine could be deemed to be "context-specific”, i.e. the CodeGen infrastructure would need to be reinitialized for each new Context. That would be a strong limitation though.<br>
><br>
> There may be other options?<br>
><br>
> —<br>
> Mehdi<br>
><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>