Snapshot of alternative DISubprogram nextAtomGroup flag approach #6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
atomGroup: n, atomRank: 0 indicates an instruction is always to be treated as a key instruction. This is currently only used in DILocation::getMergedLocation to ease the path to DISubprogram-owned nextAtomGroup counters (rather than tracking it globally).
tidy getImpl fix test.. simplfy... needs further looking at, does this need to be recursive? reduce cost of constructing dilocations add verifier check don't crash when keyinsts is disabled
This reverts commit 0bb783d093627914f1d8679e43eeff088ef71ada.
This reverts commit 4e5b7a875e11e8f02306792bca0040014e1a89c1.
OCHyams
pushed a commit
that referenced
this pull request
Jun 26, 2025
…lvm#144097) In Aya/Rust, BPF map definitions are nested in two nested types: * A struct representing the map type (e.g., `HashMap`, `RingBuf`) that provides methods for interacting with the map type (e.g. `HashMap::get`, `RingBuf::reserve`). * An `UnsafeCell`, which informs the Rust compiler that the type is thread-safe and can be safely mutated even as a global variable. The kernel guarantees map operation safety. This leads to a type hierarchy like: ```rust pub struct HashMap<K, V, const M: usize, const F: usize = 0>( core::cell::UnsafeCell<HashMapDef<K, V, M, F>>, ); const BPF_MAP_TYPE_HASH: usize = 1; pub struct HashMapDef<K, V, const M: usize, const F: usize = 0> { r#type: *const [i32; BPF_MAP_TYPE_HASH], key: *const K, value: *const V, max_entries: *const [i32; M], map_flags: *const [i32; F], } ``` Then used in the BPF program code as a global variable: ```rust #[link_section = ".maps"] static HASH_MAP: HashMap<u32, u32, 1337> = HashMap::new(); ``` Which is an equivalent of the following BPF map definition in C: ```c #define BPF_MAP_TYPE_HASH 1 struct { int (*type)[BPF_MAP_TYPE_HASH]; typeof(int) *key; typeof(int) *value; int (*max_entries)[1337]; } map_1 __attribute__((section(".maps"))); ``` Accessing the actual map definition requires traversing: ``` HASH_MAP -> __0 -> value ``` Previously, the BPF backend only visited the pointee types of the outermost struct, and didn’t descend into inner wrappers. This caused issues when the key/value types were custom structs: ```rust // Define custom structs for key and values. pub struct MyKey(u32); pub struct MyValue(u32); #[link_section = ".maps"] #[export_name = "HASH_MAP"] pub static HASH_MAP: HashMap<MyKey, MyValue, 10> = HashMap::new(); ``` These types weren’t fully visited and appeared in BTF as forward declarations: ``` llvm#30: <FWD> 'MyKey' kind:struct llvm#31: <FWD> 'MyValue' kind:struct ``` The fix is to enhance `visitMapDefType` to recursively visit inner composite members. If a member is a composite type (likely a wrapper), it is now also visited using `visitMapDefType`, ensuring that the pointee types of the innermost stuct members, like `MyKey` and `MyValue`, are fully resolved in BTF. With this fix, the correct BTF entries are emitted: ``` #6: <STRUCT> 'MyKey' sz:4 n:1 #00 '__0' off:0 --> [7] llvm#7: <INT> 'u32' bits:32 off:0 llvm#8: <PTR> --> [9] llvm#9: <STRUCT> 'MyValue' sz:4 n:1 #00 '__0' off:0 --> [7] ``` Fixes: llvm#143361
OCHyams
pushed a commit
that referenced
this pull request
Jun 30, 2025
The function already exposes a work list to avoid deep recursion, this commit starts utilizing it in a helper that could also lead to a deep recursion. We have observed this crash on `clang/test/C/C99/n590.c` with our internal builds that enable aggressive optimizations and hit the limit earlier than default release builds of Clang. See the added test for an example with a deeper recursion that used to crash in upstream Clang before this change with the following stack trace: ``` #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:804:13 #1 llvm::sys::RunSignalHandlers() /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Signals.cpp:106:18 #2 SignalHandler(int, siginfo_t*, void*) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0) #4 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12772:0 #5 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 #6 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 llvm#7 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 llvm#8 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 llvm#9 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 llvm#10 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 llvm#11 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 llvm#12 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 llvm#13 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 llvm#14 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 llvm#15 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 llvm#16 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 llvm#17 CheckCommaOperand /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:0:3 llvm#18 AnalyzeImplicitConversions /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12644:7 llvm#19 AnalyzeImplicitConversions(clang::Sema&, clang::Expr*, clang::SourceLocation, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaChecking.cpp:12776:5 ... 700+ more stack frames. ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.