diff options
| author | Mircea Trofin <mtrofin@google.com> | 2025-03-20 12:48:18 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-03-20 12:48:18 -0700 |
| commit | dd191d3d4f970a1a17e180668c3e50e2e7938cdc (patch) | |
| tree | e255e1a51f35bf0341519eb37aba605c6ade9699 /llvm/tools/llvm-objdump/llvm-objdump.cpp | |
| parent | c73ad7ba204fa05b074c1316b2244063aa10410f (diff) | |
| download | llvm-dd191d3d4f970a1a17e180668c3e50e2e7938cdc.zip llvm-dd191d3d4f970a1a17e180668c3e50e2e7938cdc.tar.gz llvm-dd191d3d4f970a1a17e180668c3e50e2e7938cdc.tar.bz2 | |
[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.
Diffstat (limited to 'llvm/tools/llvm-objdump/llvm-objdump.cpp')
0 files changed, 0 insertions, 0 deletions