================ @@ -0,0 +1,37 @@ +//===- TUSummary.h ----------------------------------------------*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#ifndef LLVM_CLANG_ANALYSIS_SCALABLE_TUSUMMARY_TUSUMMARY_H +#define LLVM_CLANG_ANALYSIS_SCALABLE_TUSUMMARY_TUSUMMARY_H + +#include "clang/Analysis/Scalable/Model/BuildNamespace.h" +#include "clang/Analysis/Scalable/Model/EntityId.h" +#include "clang/Analysis/Scalable/Model/EntityIdTable.h" +#include "clang/Analysis/Scalable/Model/SummaryName.h" +#include "clang/Analysis/Scalable/TUSummary/TUSummaryData.h" +#include <map> +#include <memory> + +namespace clang::ssaf { + +/// Data extracted for a given translation unit and for a given set of analyses. +class TUSummary { + /// Identifies the translation unit. + BuildNamespace TUNamespace; + EntityIdTable IdTable; + + std::map<SummaryName, std::map<EntityId, std::unique_ptr<TUSummaryData>>> ---------------- Xazax-hun wrote:
This is one place where the strongly typed approach might hurt the performance a bit. Having a separate `SummaryName` prevents us from using the more efficient, special purpose `llvm::StringMap` type. I wonder if it is better to just use regular string types for the summary name. (Or do we need deterministic iteration order here?) https://github.com/llvm/llvm-project/pull/176504 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
