[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -316,6 +316,15 @@ void salvageDebugInfoForDbgValues(Instruction &I, ArrayRef Insns, ArrayRef DPInsns); +void tryToSinkInstructionDbgValues( david-xl wrote: Add description for the methods.

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -2538,6 +2538,190 @@ Value *getSalvageOpsForIcmpOp(ICmpInst *Icmp, uint64_t CurrentLocOps, return Icmp->getOperand(0); } +void llvm::tryToSinkInstructionDbgValues( david-xl wrote: is there test coverage for this? https://github.com/llvm/llvm-project/pu

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -1967,11 +1969,23 @@ void llvm::updateProfileCallee( uint64_t CloneEntryCount = PriorEntryCount - NewEntryCount; for (auto Entry : *VMap) { if (isa(Entry.first)) -if (auto *CI = dyn_cast_or_null(Entry.second)) +if (auto *CI = dyn_cast_or_null(En

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,220 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,220 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [compiler-rt] [llvm] [TypeProf][InstrFDO]Implement more efficient comparison sequence for indirect-call-promotion with vtable profiles. (PR #81442)

@@ -103,30 +110,222 @@ static cl::opt ICPDUMPAFTER("icp-dumpafter", cl::init(false), cl::Hidden, cl::desc("Dump IR after transformation happens")); +// This option is meant to be used by LLVM regression test and test the +// transformation that compares vt

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -124,9 +124,27 @@ int __llvm_profile_merge_from_buffer(const char *ProfileData, SrcCountersEnd = SrcCountersStart + Header->NumCounters * __llvm_profile_counter_entry_size(); SrcNameStart = SrcCountersEnd; - SrcValueProfDataStart = + // This is to a

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -272,18 +279,26 @@ lprofWriteDataImpl(ProfDataWriter *Writer, const __llvm_profile_data *DataBegin, const uint64_t NumCounters = __llvm_profile_get_num_counters(CountersBegin, CountersEnd); const uint64_t NamesSize = DebugInfoCorrelate ? 0 : NamesEnd - NamesBegin;

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -92,6 +92,19 @@ INSTR_PROF_DATA(const uint16_t, Int16ArrayTy, NumValueSites[IPVK_Last+1], \ /* INSTR_PROF_DATA end. */ +#ifndef INSTR_PROF_VTABLE_DATA +#define INSTR_PROF_VTABLE_DATA(Type, LLVMType, Name, Initializer) +#else +#define INSTR_PROF_VTABLE_DATA_DEFINED +#endif

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -305,13 +320,24 @@ lprofWriteDataImpl(ProfDataWriter *Writer, const __llvm_profile_data *DataBegin, /* Write the profile header. */ ProfDataIOVec IOVec[] = {{&Header, sizeof(__llvm_profile_header), 1, 0}}; + // printf("Size of profile header is %d\n", + // (int)(size

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -686,9 +708,11 @@ serializeValueProfDataFrom(ValueProfRecordClosure *Closure, than WIN32 */ #define INSTR_PROF_DATA_COMMON __llvm_prf_data #define INSTR_PROF_NAME_COMMON __llvm_prf_names +#define INSTR_PROF_VNAME_COMMON __llvm_prf_vnames david-xl wrote:

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

david-xl wrote: The change looks good to me, but wait for other reviewers to chime in as well. Also a good idea to run tests with sanitizers on. https://github.com/llvm/llvm-project/pull/66164 ___ cfe-commits mailing list cfe-commits@lists.llvm.org ht

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1048,27 +1052,29 @@ class FunctionSamples { }; if (isDeclaration(SymbolMap.lookup(getFuncName( { // Add to the import list only when it's defined out of module. - S.insert(getGUID(getName())); + S.insert(getGUID()); } // Import hot Call

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1048,27 +1052,29 @@ class FunctionSamples { }; if (isDeclaration(SymbolMap.lookup(getFuncName( { // Add to the import list only when it's defined out of module. - S.insert(getGUID(getName())); + S.insert(getGUID()); } // Import hot Call

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -276,6 +286,12 @@ uint64_t __llvm_profile_get_num_counters(const char *Begin, const char *End); /*! \brief Get the size of the profile counters section in bytes. */ uint64_t __llvm_profile_get_counters_size(const char *Begin, const char *End); +uint64_t __llvm_profile_get_

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -0,0 +1,139 @@ +; RUN: opt < %s -passes=pgo-instr-gen -S | FileCheck %s --check-prefix=GEN +; RUN: opt < %s -passes=pgo-instr-gen,instrprof -S | FileCheck %s --check-prefix=LOWER + +target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" +

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -276,6 +286,12 @@ uint64_t __llvm_profile_get_num_counters(const char *Begin, const char *End); /*! \brief Get the size of the profile counters section in bytes. */ uint64_t __llvm_profile_get_counters_size(const char *Begin, const char *End); +uint64_t __llvm_profile_get_

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -276,6 +286,12 @@ uint64_t __llvm_profile_get_num_counters(const char *Begin, const char *End); /*! \brief Get the size of the profile counters section in bytes. */ uint64_t __llvm_profile_get_counters_size(const char *Begin, const char *End); +uint64_t __llvm_profile_get_

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

david-xl wrote: > The work sounds interesting. Can you provide a bit more context about it? > Will it be used to improve ICP when it's sufficient to just compare the > vtable address instead of the vfunc address? yes -- it can not only eliminate vtable load, but also enable target check combi

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -537,6 +538,9 @@ class SampleContext { assert(!Name.empty() && "Name is empty"); } + SampleContext(ProfileFuncRef Name) david-xl wrote: Name ->Func https://github.com/llvm/llvm-project/pull/66164

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -476,12 +471,12 @@ enum ContextAttributeMask { // Represents a context frame with function name and line location struct SampleContextFrame { - StringRef FuncName; + ProfileFuncRef FuncName; david-xl wrote: Nit: FuncName--> Func https://github.com/llvm

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1135,12 +1141,12 @@ class FunctionSamples { /// translate \p Name in current FunctionSamples into its original name /// by looking up in the function map GUIDToFuncNameMap. /// If the original name doesn't exist in the map, return empty StringRef. - StringRef getFunc

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -715,7 +717,7 @@ class SampleContext { private: /// Mangled name of the function. - StringRef Name; + ProfileFuncRef Name; david-xl wrote: Name --> Func https://github.com/llvm/llvm-project/pull/66164 ___ cf

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -537,6 +538,9 @@ class SampleContext { assert(!Name.empty() && "Name is empty"); } + SampleContext(ProfileFuncRef Name) david-xl wrote: Name ->Func https://github.com/llvm/llvm-project/pull/66164

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,225 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1048,27 +1052,29 @@ class FunctionSamples { }; if (isDeclaration(SymbolMap.lookup(getFuncName( { // Add to the import list only when it's defined out of module. - S.insert(getGUID(getName())); + S.insert(getGUID()); } // Import hot Call

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1048,27 +1052,29 @@ class FunctionSamples { }; if (isDeclaration(SymbolMap.lookup(getFuncName( { // Add to the import list only when it's defined out of module. - S.insert(getGUID(getName())); + S.insert(getGUID()); } // Import hot Call

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -643,14 +648,11 @@ class SampleContext { uint64_t getHashCode() const { if (hasContext()) return hash_value(getContextFrames()); - -// For non-context function name, use its MD5 as hash value, so that it is -// consistent with the profile map's key. -

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,225 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -574,7 +578,7 @@ class SampleContext { ContextStr = ContextStr.substr(1, ContextStr.size() - 2); StringRef ContextRemain = ContextStr; StringRef ChildContext; -StringRef CalleeName; +ProfileFuncRef CalleeName; david-xl wrote: CalleeName

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,226 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1048,27 +1052,29 @@ class FunctionSamples { }; if (isDeclaration(SymbolMap.lookup(getFuncName( { // Add to the import list only when it's defined out of module. - S.insert(getGUID(getName())); + S.insert(getGUID()); } // Import hot Call

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -715,7 +717,7 @@ class SampleContext { private: /// Mangled name of the function. - StringRef Name; + ProfileFuncRef Name; david-xl wrote: Name --> Func https://github.com/llvm/llvm-project/pull/66164 ___ cf

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -1135,12 +1141,12 @@ class FunctionSamples { /// translate \p Name in current FunctionSamples into its original name /// by looking up in the function map GUIDToFuncNameMap. /// If the original name doesn't exist in the map, return empty StringRef. - StringRef getFunc

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,225 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -574,7 +578,7 @@ class SampleContext { ContextStr = ContextStr.substr(1, ContextStr.size() - 2); StringRef ContextRemain = ContextStr; StringRef ChildContext; -StringRef CalleeName; +ProfileFuncRef CalleeName; david-xl wrote: CalleeName

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -643,14 +648,11 @@ class SampleContext { uint64_t getHashCode() const { if (hasContext()) return hash_value(getContextFrames()); - -// For non-context function name, use its MD5 as hash value, so that it is -// consistent with the profile map's key. -

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,226 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

https://github.com/david-xl commented: Is there a need to have a separate vtable name section? Merging the vtable names with function name table can make the implementation simpler. https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mail

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

@@ -177,13 +195,22 @@ VALUE_PROF_FUNC_PARAM(uint32_t, CounterIndex, Type::getInt32Ty(Ctx)) VALUE_PROF_KIND(IPVK_IndirectCallTarget, 0, "indirect call target") /* For memory intrinsic functions size profiling. */ VALUE_PROF_KIND(IPVK_MemOPSize, 1, "memory intrinsic functions si

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

https://github.com/david-xl edited https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

https://github.com/david-xl commented: Is there a need to have a separate vtable name section? Merging the vtable names with function name table can make the implementation simpler. https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mail

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString;

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- 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: Ap

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- 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: Ap

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

david-xl wrote: The performance win depends a lot on value distribution. For large copies, using SIMD with nontemporal hint is the way to go. https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,222 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString;

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,222 @@ +//===--- ProfileFuncRef.h - Sample profile function name ---*- 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

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm] [NFCI]Remove EntryCount from FunctionSummary and clean up surrounding synthetic count passes. (PR #107471)

https://github.com/david-xl approved this pull request. Thanks for the cleanup. https://github.com/llvm/llvm-project/pull/107471 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D84782: [PGO] Include the mem ops into the function hash.

right. It occurred to me during review, but did not think of the hard coded values in proftext depends on LE. On Wed, Jul 29, 2020 at 3:04 PM Hiroshi Yamauchi via Phabricator < revi...@reviews.llvm.org> wrote: > yamauchi added a comment. > > Builtbot failure: > http://lab.llvm.org:8011/builders/c

Re: [PATCH] D84261: [PGO] Supporting code for always instrumenting entry block

I think you are right -- the two files need to be in sync. On Mon, Aug 17, 2020 at 1:17 PM Pavel Kosov via Phabricator via llvm-commits wrote: > kpdev42 added inline comments. > > > > Comment at: llvm/include/llvm/ProfileData/InstrProfData.inc:676 > #define VARIANT_MASK_CSIR_PR

Re: [PATCH] D63155: [clang][NewPM] Fix broken profile test

I agree that the test coverage needs to be improved eg better check etc. David On Fri, Jun 28, 2019 at 5:21 PM Chandler Carruth via Phabricator via llvm-commits wrote: > chandlerc added a comment. > > In D63155#1563275 , @xur wrote: > > > In D63155#156

Re: [PATCH] D45454: Make __gcov_flush visible outside a shared library

I don't have an objection having another interface which is just a simple wrapper to __gcov_flush but with default visibility. Also clearly document its usage and behavior. David On Mon, Jun 25, 2018 at 10:12 AM, Chih-Hung Hsieh via Phabricator via llvm-commits wrote: > chh added a comment. > >

Re: [PATCH] D45454: Make __gcov_flush visible outside a shared library

On Wed, Apr 11, 2018 at 11:31 AM, Chih-Hung Hsieh via Phabricator via llvm-commits wrote: > chh added a comment. > > Yes, calling `__gcov_flush` within .so files are different, > but it's a revert of https://reviews.llvm.org/D38124. > I think https://bugs.llvm.org/show_bug.cgi?id=27224 > can be

r253846 - Disable frame pointer elimination when using -pg

Author: davidxl Date: Sun Nov 22 23:09:10 2015 New Revision: 253846 URL: http://llvm.org/viewvc/llvm-project?rev=253846&view=rev Log: Disable frame pointer elimination when using -pg This diff makes sure that the driver does not pass -fomit-frame-pointer or -momit-leaf-frame-pointer to the fronte

r253851 - Revert r253846 (build bot failure))

Author: davidxl Date: Sun Nov 22 23:41:05 2015 New Revision: 253851 URL: http://llvm.org/viewvc/llvm-project?rev=253851&view=rev Log: Revert r253846 (build bot failure)) Removed: cfe/trunk/test/CodeGen/x86_64-profiling-keep-fp.c Modified: cfe/trunk/lib/Driver/Tools.cpp cfe/trunk/lib/F

r253886 - Disable frame pointer elimination when using -pg

Author: davidxl Date: Mon Nov 23 11:30:31 2015 New Revision: 253886 URL: http://llvm.org/viewvc/llvm-project?rev=253886&view=rev Log: Disable frame pointer elimination when using -pg (Re-apply patch after bug fixing) This diff makes sure that the driver does not pass -fomit-frame-pointer or -mo

r254839 - Pass profile version info to name API (NFC)

Author: davidxl Date: Fri Dec 4 23:37:15 2015 New Revision: 254839 URL: http://llvm.org/viewvc/llvm-project?rev=254839&view=rev Log: Pass profile version info to name API (NFC) Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp URL: http://llvm.or

r255326 - [PGO] Add a test case to cover version-3 format

Author: davidxl Date: Thu Dec 10 22:02:57 2015 New Revision: 255326 URL: http://llvm.org/viewvc/llvm-project?rev=255326&view=rev Log: [PGO] Add a test case to cover version-3 format Added: cfe/trunk/test/Profile/Inputs/c-general.profdata.v3 (with props) Modified: cfe/trunk/test/Profile/

r255366 - [PGO] Stop using invalid char in instr variable names.

Author: davidxl Date: Fri Dec 11 13:53:35 2015 New Revision: 255366 URL: http://llvm.org/viewvc/llvm-project?rev=255366&view=rev Log: [PGO] Stop using invalid char in instr variable names. (This is part-2 of the patch -- fixing test cases) Before the patch, -fprofile-instr-generate compile will

r255368 - [PGO] Revert r255366: solution incomplete, not handling lambda yet

Author: davidxl Date: Fri Dec 11 14:23:12 2015 New Revision: 255368 URL: http://llvm.org/viewvc/llvm-project?rev=255368&view=rev Log: [PGO] Revert r255366: solution incomplete, not handling lambda yet Modified: cfe/trunk/test/CoverageMapping/unused_names.c cfe/trunk/test/Profile/Inputs/c-

r255435 - [PGO] Stop using invalid char in instr variable names.

Author: davidxl Date: Sat Dec 12 11:28:37 2015 New Revision: 255435 URL: http://llvm.org/viewvc/llvm-project?rev=255435&view=rev Log: [PGO] Stop using invalid char in instr variable names. (This is part-2 of the patch of r255434 -- fixing test cases, second try) Modified: cfe/trunk/test/Co

r255436 - [PGO] add a test case with -no-integrated-as

Author: davidxl Date: Sat Dec 12 11:39:38 2015 New Revision: 255436 URL: http://llvm.org/viewvc/llvm-project?rev=255436&view=rev Log: [PGO] add a test case with -no-integrated-as Added: cfe/trunk/test/Profile/cxx-static.cpp Added: cfe/trunk/test/Profile/cxx-static.cpp URL: http://llvm.org/v

r255437 - Revert 255436 : remove test that needs to be refined

Author: davidxl Date: Sat Dec 12 12:49:37 2015 New Revision: 255437 URL: http://llvm.org/viewvc/llvm-project?rev=255437&view=rev Log: Revert 255436 : remove test that needs to be refined Removed: cfe/trunk/test/Profile/cxx-static.cpp Removed: cfe/trunk/test/Profile/cxx-static.cpp URL: http:

r255445 - Resubmit new test case after adding more constraint

Author: davidxl Date: Sat Dec 12 21:03:35 2015 New Revision: 255445 URL: http://llvm.org/viewvc/llvm-project?rev=255445&view=rev Log: Resubmit new test case after adding more constraint Added: cfe/trunk/test/Profile/cxx-static.cpp Added: cfe/trunk/test/Profile/cxx-static.cpp URL: http://llv

r255447 - Revert r255445: adding a new test case

Author: davidxl Date: Sat Dec 12 22:45:49 2015 New Revision: 255447 URL: http://llvm.org/viewvc/llvm-project?rev=255447&view=rev Log: Revert r255445: adding a new test case Removed: cfe/trunk/test/Profile/cxx-static.cpp Removed: cfe/trunk/test/Profile/cxx-static.cpp URL: http://llvm.org/vie

Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.

On Fri, Dec 11, 2015 at 6:19 PM, Justin Bogner wrote: > Easwaran Raman writes: >> eraman updated this revision to Diff 42549. >> eraman added a comment. >> >> Added a test case. >> >> >> Repository: >> rL LLVM >> >> http://reviews.llvm.org/D15163 >> >> Files: >> lib/CodeGen/CodeGenModule.cpp

Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.

On Fri, Dec 11, 2015 at 6:19 PM, Justin Bogner wrote: > Easwaran Raman writes: >> eraman updated this revision to Diff 42549. >> eraman added a comment. >> >> Added a test case. >> >> >> Repository: >> rL LLVM >> >> http://reviews.llvm.org/D15163 >> >> Files: >> lib/CodeGen/CodeGenModule.cpp

r255576 - [PGO] Shorten profile symbol prefixes

Author: davidxl Date: Mon Dec 14 17:26:46 2015 New Revision: 255576 URL: http://llvm.org/viewvc/llvm-project?rev=255576&view=rev Log: [PGO] Shorten profile symbol prefixes (test case update) Profile symbols have long prefixes which waste space and creating pressure for linker. This patch shorten

r255587 - [PGO] make profile prefix even shorter and more readable

Author: davidxl Date: Mon Dec 14 18:33:12 2015 New Revision: 255587 URL: http://llvm.org/viewvc/llvm-project?rev=255587&view=rev Log: [PGO] make profile prefix even shorter and more readable Modified: cfe/trunk/test/CoverageMapping/ir.c cfe/trunk/test/CoverageMapping/unused_names.c cf

r256714 - [PGO] Cleanup: Use covmap header definition in the template file

Author: davidxl Date: Sun Jan 3 13:25:54 2016 New Revision: 256714 URL: http://llvm.org/viewvc/llvm-project?rev=256714&view=rev Log: [PGO] Cleanup: Use covmap header definition in the template file This is one last remaining instrumentatation related structure that needs to be migrate to use the

Re: [PATCH] D13319: Eliminate __llvm_profile_register calls

On Wed, Sep 30, 2015 at 5:42 PM, Justin Bogner wrote: > David Li writes: >> davidxl created this revision. >> davidxl added reviewers: bogner, rsmith. >> davidxl added subscribers: cfe-commits, llvm-commits. >> Herald added subscribers: srhines, danalbert, tberghammer. >> >> With PGO, the instrum

Re: [PATCH] D13326: [PGO]: Eliminate __llvm_profile_register calls for Linux (clang changes)

Clang FE refactoring change is not needed anymore. In commit 0d32e7d952bc80830183e0c2c6ec5027ca6b1450, Vasileios Kalintiris did the same thing for multi-lib support. David On Tue, Oct 6, 2015 at 12:13 AM, Justin Bogner wrote: > David Li writes: >> davidxl updated this revision to Diff 36316. >

r305325 - Preserve cold attribute for function decls

Author: davidxl Date: Tue Jun 13 16:14:07 2017 New Revision: 305325 URL: http://llvm.org/viewvc/llvm-project?rev=305325&view=rev Log: Preserve cold attribute for function decls Differential Revision: http://reviews.llvm.org/D34133 Modified: cfe/trunk/lib/CodeGen/CGCall.cpp cfe/trunk/te

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator < revi...@reviews.llvm.org> wrote: > chandlerc added a comment. > > I'm really not a fan of the degree of complexity and subtlety that this > introduces into the frontend, all to allow particular backend optimizations. > > I feel li

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits < llvm-comm...@lists.llvm.org> wrote: > On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carrut

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

lists.llvm.org> wrote: >> >>> On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> >>>> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator < >>>> revi...@revi

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while the store forwarding stalls cost about 10 cycles more than a successful store forwarding, which is roughly 15 cycles. In some scenarios, the store forw

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

I think we can think this in another way. For modern CPU architectures which supports store forwarding with store queues, it is generally not "safe" to blindly do local optimizations to widen the load/stores without sophisticated inter-procedural analysis. Doing so will run the risk of greatly red

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Sun, Sep 3, 2017 at 9:23 PM, Hal Finkel wrote: > > On 09/03/2017 11:06 PM, Xinliang David Li wrote: > > I think we can think this in another way. > > For modern CPU architectures which supports store forwarding with store > queues, it is generally not "safe" to blindly do local optimizations t

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Mon, Sep 4, 2017 at 9:17 AM, Hal Finkel wrote: > > On 09/04/2017 03:57 AM, Chandler Carruth wrote: > > On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits < > llvm-comm...@lists.llvm.org> wrote: > >> Nevertheless, I think that you've convinced me that this is a least-bad >> solution. I

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On Mon, Sep 4, 2017 at 1:57 AM, Chandler Carruth wrote: > On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits < > llvm-comm...@lists.llvm.org> wrote: > >> Nevertheless, I think that you've convinced me that this is a least-bad >> solution. I'll want a flag preserving the old behavior. Som

r300279 - [Profile] PE binary coverage bug fix

Author: davidxl Date: Thu Apr 13 18:37:21 2017 New Revision: 300279 URL: http://llvm.org/viewvc/llvm-project?rev=300279&view=rev Log: [Profile] PE binary coverage bug fix PR/32584 Differential Revision: https://reviews.llvm.org/D32023 Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp

r300301 - Remove unused function /nfc

Author: davidxl Date: Thu Apr 13 22:01:25 2017 New Revision: 300301 URL: http://llvm.org/viewvc/llvm-project?rev=300301&view=rev Log: Remove unused function /nfc Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp URL: http://llvm.or

r300304 - Fix use after free error

Author: davidxl Date: Thu Apr 13 23:14:29 2017 New Revision: 300304 URL: http://llvm.org/viewvc/llvm-project?rev=300304&view=rev Log: Fix use after free error Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp URL: http://llvm.org/v

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

On Fri, Jul 1, 2016 at 4:32 PM, Sean Silva wrote: > silvas added inline comments. > > > Comment at: lib/Driver/Tools.cpp:3560 > @@ +3559,3 @@ > +if (PGOTrainArg->getOption().matches(options::OPT_fpgo_train_EQ)) { > + if (StringRef(PGOTrainArg->getValue()) == "source-cfg"

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

Sanitizers are different IMO. Different santizers are rather independent, and there is no such thing as -fsantize to mean -fsantize=all For PGO, in most of the cases, users do not need to care about the sub-options implied -- by default they should just get the best profiling (whatever that is). F

<    1   2   3   4   >