Hi all, 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. There are two issues: 1) What if they differ? I guess we could assert at the beginning of CodeGen. 2) The DataLayout has internal mutable state (a cache of StructLayout). The latter is my current concern: the cache in DataLayout is based on Type pointer which means that is has to be Context specific. This is fine with the DataLayout attached to the Module but not with the TargetMachine. The cache could live in the Context, but it is also DataLayout specific so it wouldn’t be a good fit either. 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). 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. 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. There may be other options? — Mehdi
Long term I think we should keep only the one in the module. On 24 June 2015 at 14:42, Mehdi Amini <mehdi.amini at apple.com> wrote:> Hi all, > > 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. > There are two issues: > 1) What if they differ? I guess we could assert at the beginning of CodeGen. > 2) The DataLayout has internal mutable state (a cache of StructLayout). > > The latter is my current concern: the cache in DataLayout is based on Type pointer which means that is has to be Context specific. > This is fine with the DataLayout attached to the Module but not with the TargetMachine. > The cache could live in the Context, but it is also DataLayout specific so it wouldn’t be a good fit either. > > 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). > > 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. > > 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. > > There may be other options? > > — > Mehdi > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Agreed. I'll reply to the rest of it soon, but if we have a required one in the module then that's what we should use. -eric On Thu, Jun 25, 2015 at 10:05 AM Rafael Espíndola < rafael.espindola at gmail.com> wrote:> Long term I think we should keep only the one in the module. > > > On 24 June 2015 at 14:42, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi all, > > > > 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. > > There are two issues: > > 1) What if they differ? I guess we could assert at the beginning of > CodeGen. > > 2) The DataLayout has internal mutable state (a cache of StructLayout). > > > > The latter is my current concern: the cache in DataLayout is based on > Type pointer which means that is has to be Context specific. > > This is fine with the DataLayout attached to the Module but not with the > TargetMachine. > > The cache could live in the Context, but it is also DataLayout specific > so it wouldn’t be a good fit either. > > > > 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). > > > > 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. > > > > 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. > > > > There may be other options? > > > > — > > Mehdi > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150625/e7e2fb02/attachment.html>
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. 2015-06-25 15:57 GMT+03:00 Rafael Espíndola <rafael.espindola at gmail.com>:> Long term I think we should keep only the one in the module. > > > On 24 June 2015 at 14:42, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi all, > > > > 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. > > There are two issues: > > 1) What if they differ? I guess we could assert at the beginning of > CodeGen. > > 2) The DataLayout has internal mutable state (a cache of StructLayout). > > > > The latter is my current concern: the cache in DataLayout is based on > Type pointer which means that is has to be Context specific. > > This is fine with the DataLayout attached to the Module but not with the > TargetMachine. > > The cache could live in the Context, but it is also DataLayout specific > so it wouldn’t be a good fit either. > > > > 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). > > > > 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. > > > > 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. > > > > There may be other options? > > > > — > > Mehdi > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150625/a8ff1d75/attachment.html>