================ @@ -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>>> ---------------- aviralg wrote:
1. Honestly, I am not worried about performance here. We will have millions of entities (inner map) compared to a dozen or so summaries. 2. It's always helpful to keep things abstract so we can change their implementation details in the future. Having said that, I can't imagine a reasonable alternative implementation of `SummaryName` that is not a string. 3. The Entity Linker uses this data structure in many places. It can be easily updated to use a string directly, if needed. My suggestion - We can keep `SummaryName` as is for now. If profiling suggests this to be a performance bottleneck, we can replace it with a string. https://github.com/llvm/llvm-project/pull/176504 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
