craig.topper added a comment. In D83273#2195033 <https://reviews.llvm.org/D83273#2195033>, @nickdesaulniers wrote:
> In D83273#2194869 <https://reviews.llvm.org/D83273#2194869>, @echristo wrote: > >> That said, it's a 10% compile time regression for compiling something like >> the linux kernel or anything that's very explicit what flags they set. > > Digging into the profile a little deeper: > > + 9.20% [.] getImpliedDisabledFeatures > + 1.46% [.] llvm::X86::getImpliedFeatures > - 3.00% llvm::StringMapImpl::LookupBucketFor > + 1.55% llvm::StringMap<clang::IdentifierInfo*, > llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, 4096ul, 4096ul, 128ul> > >::try_emplace<clang::IdentifierInfo*> > - 1.11% llvm::StringMap<bool, llvm::MallocAllocator>::try_emplace<> > + 1.11% clang::targets::X86TargetInfo::setFeatureEnabled > + 1.46% [.] llvm::X86::getImpliedFeatures > > so potentially a 13.23% compile time savings for the entire codebase. I started on a patch to cache the feature map calculated in TargetInfo::CreateTargetInfo and use it whenever there isn't a target attribute instead of rebuilding it from the cached feature vector. Unfortunatley, that seems to be failing a WebAssembly test because they use some flags in initFeatureMap that are set by handleTargetFeatures which is called after initFeatureMap is called the first time. So the map is different when initFeatureMap is called from Sema and CodeGen can be different than the map created in TargetInfo::CreateTargetInfo so the cache doesn't work. I'll work with WebAssembly folks to see if this was intentional behavior. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83273/new/ https://reviews.llvm.org/D83273 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
