[all-commits] [llvm/llvm-project] dd191d: [ctxprof][nfc] Share the definition of FunctionDat...

[Mircea Trofin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dd191d3d4f970a1a17e180668c3e50e2e7938cdc
      https://github.com/llvm/llvm-project/commit/dd191d3d4f970a1a17e180668c3e50e2e7938cdc
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2025-03-20 (Thu, 20 Mar 2025)

  Changed paths:
    M compiler-rt/lib/ctx_profile/CtxInstrContextNode.h
    M compiler-rt/lib/ctx_profile/CtxInstrProfiling.h
    M llvm/include/llvm/ProfileData/CtxInstrContextNode.h
    M llvm/lib/Transforms/Instrumentation/PGOCtxProfLowering.cpp

  Log Message:
  -----------
  [ctxprof][nfc] Share the definition of FunctionData between compiler-rt and llvm (#132136)

Mechanism to keep the compiler-rt and llvm view of `FunctionData` in sync. Since CtxInstrContextNode.h is exactly the same on both sides (there's an existing test, `compiler-rt/test/ctx_profile/TestCases/check-same-ctx-node.test`, checking that), we capture the structure in a macro that is then generated as `struct` fields on the compiler-rt side, and as `Type` objects on the llvm side. The macro needs to be told how to render a few kinds of fields. 

If we add more fields to FunctionData that can be described by the current known types of fields, then the llvm side would automatically be updated. If we need to add more kinds of fields, which we do by adding parameters to the macro, the llvm side (if not updated) would trigger a compilation error.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications