aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-01-13[CodeGen] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFCCraig Topper1-11/+8
Use isPhysical/isVirtual methods. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D141715
2023-01-06[DebugInfo] Allow non-stack_value variadic expressions and use in DBG_INSTR_REFStephen Tozer1-2/+1
Prior to this patch, variadic DIExpressions (i.e. ones that contain DW_OP_LLVM_arg) could only be created by salvaging debug values to create stack value expressions, resulting in a DBG_VALUE_LIST being created. As of the previous patch in this patch stack, DBG_INSTR_REF's syntax has been changed to match DBG_VALUE_LIST in preparation for supporting variadic expressions. This patch adds some minor changes needed to allow variadic expressions that aren't stack values to exist, and allows variadic expressions that are trivially reduceable to non-variadic expressions to be handled similarly to non-variadic expressions. Reviewed by: jmorse Differential Revision: https://reviews.llvm.org/D133926
2023-01-06[DebugInfo][NFC] Add new MachineOperand type and change DBG_INSTR_REF syntaxStephen Tozer1-3/+7
This patch makes two notable changes to the MIR debug info representation, which result in different MIR output but identical final DWARF output (NFC w.r.t. the full compilation). The two changes are: * The introduction of a new MachineOperand type, MO_DbgInstrRef, which consists of two unsigned numbers that are used to index an instruction and an output operand within that instruction, having a meaning identical to first two operands of the current DBG_INSTR_REF instruction. This operand is only used in DBG_INSTR_REF (see below). * A change in syntax for the DBG_INSTR_REF instruction, shuffling the operands to make it resemble DBG_VALUE_LIST instead of DBG_VALUE, and replacing the first two operands with a single MO_DbgInstrRef-type operand. This patch is the first of a set that will allow DBG_INSTR_REF instructions to refer to multiple machine locations in the same manner as DBG_VALUE_LIST. Reviewed By: jmorse Differential Revision: https://reviews.llvm.org/D129372
2022-12-13[CodeGen] llvm::Optional => std::optionalFangrui Song1-7/+8
2022-12-04DebugInfoMetadata: convert Optional to std::optionalKrzysztof Parzyszek1-6/+8
2022-12-02[CodeGen] Use std::nullopt instead of None (NFC)Kazu Hirata1-2/+2
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-07-17[CodeGen] Qualify auto variables in for loops (NFC)Kazu Hirata1-1/+1
2022-06-20[llvm] Don't use Optional::hasValue (NFC)Kazu Hirata1-1/+1
2022-04-26Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHIJeremy Morse1-2/+19
This was reverted twice, in 987cd7c3ed75b and 13815e8cbf8d4. The latter stemed from not accounting for rare register classes in a pre-allocated array, and the former from an array not being completely initialized, leading to asan complaining.
2022-04-25Revert "Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI"Jeremy Morse1-19/+2
This reverts commit 5db925023169f8a19419e68153682d1e518f8392. Further to the early revert, the sanitizers have found something wrong with this.
2022-04-25Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHIJeremy Morse1-2/+19
This was applied in fda4305e53784, reverted in 13815e8cbf8d49, the problem was that fp80 X86 registers that were spilt to the stack aren't expected by LiveDebugValues. It pre-allocates a position number for all register sizes that can be spilt, and 80 bits isn't exactly common. The solution is to scan the register classes to find any unrecognised register sizes, adn pre-allocate those position numbers, avoiding a later assertion.
2022-04-25Revert "[DebugInfo][InstrRef] Add a size operand to DBG_PHI"Jeremy Morse1-19/+2
This reverts commit fda4305e5378478051be225248bfe9c1d401d938. Green dragon has spotted a problem -- it's understood, but might be fiddly to fix, reverting in the meantime.
2022-04-25[DebugInfo][InstrRef] Add a size operand to DBG_PHIJeremy Morse1-2/+19
DBG_PHI instructions can refer to stack slots, to indicate that multiple values merge together on control flow joins in that slot. This is fine -- however the slot might be merged at a later date with a slot of a different size. In doing so, we lose information about the size the eliminated PHI. Later analysis passes have to guess. Improve this by attaching an optional "bit size" operand to DBG_PHI, which only gets added for stack slots, to let us know how large a size the value on the stack is. Differential Revision: https://reviews.llvm.org/D124184
2022-03-16Cleanup codegen includesserge-sans-paille1-5/+0
This is a (fixed) recommit of https://reviews.llvm.org/D121169 after: 1061034926 before: 1063332844 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121681
2022-03-10Revert "Cleanup codegen includes"Nico Weber1-0/+5
This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20. Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang, and many LLVM tests, see comments on https://reviews.llvm.org/D121169
2022-03-10Cleanup codegen includesserge-sans-paille1-5/+0
after: 1061034926 before: 1063332844 Differential Revision: https://reviews.llvm.org/D121169
2022-02-04Reduce dependencies on llvm/BinaryFormat/Dwarf.hserge-sans-paille1-0/+1
This header is very large (3M Lines once expended) and was included in location where dwarf-specific information were not needed. More specifically, this commit suppresses the dependencies on llvm/BinaryFormat/Dwarf.h in two headers: llvm/IR/IRBuilder.h and llvm/IR/DebugInfoMetadata.h. As these headers (esp. the former) are widely used, this has a decent impact on number of preprocessed lines generated during compilation of LLVM, as showcased below. This is achieved by moving some definitions back to the .cpp file, no performance impact implied[0]. As a consequence of that patch, downstream user may need to manually some extra files: llvm/IR/IRBuilder.h no longer includes llvm/BinaryFormat/Dwarf.h llvm/IR/DebugInfoMetadata.h no longer includes llvm/BinaryFormat/Dwarf.h In some situations, codes maybe relying on the fact that llvm/BinaryFormat/Dwarf.h was including llvm/ADT/Triple.h, this hidden dependency now needs to be explicit. $ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Transforms/Scalar/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l after: 10978519 before: 11245451 Related Discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup [0] https://llvm-compile-time-tracker.com/compare.php?from=fa7145dfbf94cb93b1c3e610582c495cb806569b&to=995d3e326ee1d9489145e20762c65465a9caeab4&stat=instructions Differential Revision: https://reviews.llvm.org/D118781
2022-01-07[llvm] Use true/false instead of 1/0 (NFC)Kazu Hirata1-1/+1
Identified with modernize-use-bool-literals.
2021-12-05[GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.Jack Andersen1-3/+0
Expanding on D109750. Since `DBG_VALUE` instructions have final register validity determined in `LDVImpl::handleDebugValue`, there is no apparent reason to immediately prune unused register operands as their defs are erased. Consequently, this renders `MachineInstr::eraseFromParentAndMarkDBGValuesForRemoval` moot; gaining a substantial performance improvement. The only necessary changes involve making relevant passes consider invalid DBG_VALUE vregs uses as valid. Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D112852
2021-12-03[CodeGen] Use range-based for loops (NFC)Kazu Hirata1-4/+4
2021-11-25[DebugInfo][InstrRef] Avoid some quadratic behaviour in LiveDebugVariablesJeremy Morse1-14/+37
This is a performance patch -- LiveDebugVariables can behave quadratically if a lot of debug instructions are inserted back into the same place, and we have to repeatedly step-over hte ones we've already inserted. To get around it, whenever we insert a debug instruction at a slot index, check whether there are more debug instructions to insert at this point, and insert them too. That avoids the repeated lookup and stepping through. It relies on the container for unlinked debug instructions being recorded in-order, which is how LiveDebugVariables currently does it. Differential Revision: https://reviews.llvm.org/D114587
2021-11-01[CodeGen] Use make_early_inc_range (NFC)Kazu Hirata1-7/+3
2021-09-17[CodeGen] LiveDebug - Use const-ref iterator in for-range loop. NFCI.Simon Pilgrim1-1/+1
Avoid unnecessary copies, reported by MSVC static analyzer.
2021-08-25[DebugInfo][InstrRef] Don't use instr-ref for unoptimised functionsJeremy Morse1-6/+1
InstrRefBasedLDV is marginally slower than VarlocBasedLDV when analysing optimised code -- however, it's much slower when analysing code compiled -O0. To avoid this: don't use instruction referencing for -O0 functions. In the "pure" case of unoptimised code, this won't really harm the debugging experience because most variables won't have been promoted off the stack, so can't go missing. It becomes more complicated when optimised code is inlined into functions marked optnone; however these are rare, and as -O0 doesn't run many optimisations there should be little damage to the debug experience as a result. I've taken the opportunity to refactor testing for instruction-referencing into a MachineFunction method, which seems the most appropriate place to put it. Differential Revision: https://reviews.llvm.org/D108585
2021-07-08[DebugInfo][InstrRef][4/4] Support DBG_INSTR_REF through all backend passesJeremy Morse1-50/+107
This is a cleanup patch -- we're now able to support all flavours of variable location in instruction referencing mode. This patch updates various tests for debug instructions to be broader: numerous code paths try to ignore debug isntructions, and they now have to ignore the additional DBG_PHI and DBG_INSTR_REFs that we can generate. A small amount of rework happens for LiveDebugVariables: as we don't need to track live intervals through regalloc any more, we can get away with unlinking debug instructions before regalloc, then re-inserting them after. Note that this isn't (yet) true of DBG_VALUE_LISTs, they still have to go through live interval tracking. In SelectionDAG, add a helper lambda that emits half-formed DBG_INSTR_REFs for arguments in instr-ref mode, DBG_VALUE otherwise. This is one of the final locations where DBG_VALUEs are emitted for vreg arguments. X86InstrInfo now un-sets the debug instr number on SUB instructions that get mutated into CMP instructions. As the instruction no longer computes a subtraction, we can't use it for variable locations. Differential Revision: https://reviews.llvm.org/D88898
2021-05-31[LiveDebugVariables] Stop trimming locations of non-inlined varsDjordje Todorovic1-1/+5
The D35953, D62650 and D73691 introduced trimming of variables locations in LiveDebugVariables pass, since there are some cases where after the virtregrewrite we have exploded number of DBG_VALUEs created for some inlined variables. As it looks, all problematic cases were regarding inlined variables, so it seems reasonable to stop trimming the location ranges for non-inlined variables. It has very good impact on the llvm-locstats report. Differential Revision: https://reviews.llvm.org/D102917
2021-05-26[DebugInstrRef][1/3] Track PHI values through register allocationJeremy Morse1-1/+122
This patch introduces "DBG_PHI" instructions, a marker of where a PHI instruction used to be, before PHI elimination. Under the instruction referencing model, we want to know where every value in the function is defined -- and a PHI, even if implicit, is such a place. Just like instruction numbers, we can use this to identify a value to be used as a variable value, but we don't need to know what instruction defines that value, for example: bb1: DBG_PHI $rax, 1 [... more insts ... ] bb2: DBG_INSTR_REF 1, 0, !1234, !DIExpression() This specifies that on entry to bb1, whatever value is in $rax is known as value number one -- and the later DBG_INSTR_REF marks the position where variable !1234 should take on value number one. PHI locations are stored in MachineFunction for the duration of the regalloc phase in the DebugPHIPositions map. The map is populated by PHIElimination, and then flushed back into the instruction stream by virtregrewriter. A small amount of maintenence is needed in LiveDebugVariables to account for registers being split, but only for individual positions, not for entire ranges of blocks. Differential Revision: https://reviews.llvm.org/D86812
2021-05-07Reapply "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug ↵Stephen Tozer1-11/+27
operands" Reapply b623df3c, which was reverted while reverting a different patch with a breaking change. There are no underlying issues with this patch, so no changes have been made to the original patch. This reverts commit b11e4c990771541e440861f017afea7b4ba162f4.
2021-05-07[CodeGen] Ensure UserValue::getDebugLoc() and UserLabel::getDebugLoc() ↵Simon Pilgrim1-2/+2
consistently return a const reference NFCI. Avoids a lot of unnecessary tracking increments/decrements of the underlying TrackingMDNodeRef.
2021-04-30Revert "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug ↵Nick Desaulniers1-27/+11
operands" This reverts commit b623df3c93983c4512aa54f2c706716bdf865a90, as per https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy. Breakages observed downstream reported in: https://reviews.llvm.org/D91722#2724321 Fixes exist in: https://reviews.llvm.org/D101523 https://reviews.llvm.org/D101540 but haven't landed yet going into the weekend.
2021-04-28[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operandsStephen Tozer1-11/+27
This patch fixes a crash in LiveDebugVariables for inputs where a DBG_VALUE_LIST had 64 or more debug operands. This was triggering an assert, which was added under the assumption that only bad CodeGen would result in such a limit being hit, but relatively simple source files that result in these incredibly long debug values have been found, so this assert has been changed to a condition that drops the debug value if it is not met. Differential Revision: https://reviews.llvm.org/D101373
2021-04-19[CSSPGO] Exclude pseudo probes from slot indexHongtao Yu1-2/+2
Pseudo probe are currently given a slot index like other regular instructions. This affects register pressure and lifetime weight computation because of enlarged lifetime length with pseudo probe instructions. As a consequence, program could get different code generated w/ and w/o pseudo probes. I'm closing the gap by excluding pseudo probes from stack index and downstream register allocation related passes. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D100334
2021-03-10[DebugInfo] Process DBG_VALUE_LIST in LiveDebugVariablesgbtozers1-200/+400
This patch adds support for DBG_VALUE_LIST in the LiveDebugVariables pass. The changes are mostly in computeIntervals, extendDef, and addDefsFromCopies; when extending the def of a DBG_VALUE_LIST the live ranges of every used register must be considered, and when such a def is killed by more than one of its used registers being killed at the same time it is necessary to find valid copies of all of those registers to create a new def with. The DebugVariableValue class has also been changed to reference multiple location numbers instead of just one. This has been accomplished by using a C-style array with a unique_ptr and an array length packed into 6 bits, to minimize the size of the class (which must be kept low to be used with IntervalMap). This may not be the most efficient solution possible, and should be looked at if performance issues arise. Differential Revision: https://reviews.llvm.org/D83895
2021-02-13[CodeGen] Use range-based for loops (NFC)Kazu Hirata1-7/+5
2021-01-28[LiveDebugVariables] Add cache for SkipPHIsLabelsAndDebug to preventWei Mi1-20/+64
iterating the same PHI/LABEL/Debug instructions repeatedly. We run into a compiling timeout problem when building a target after its SampleFDO profile is updated. It is because some very large blocks with a bunch of PHIs at the beginning. LiveDebugVariables::emitDebugValues called during VirtRegRewriter phase searchs the insertion point for those large BBs repeatedly in SkipPHIsLabelsAndDebug, and each time SkipPHIsLabelsAndDebug needs to go through the same set of PHIs before it can find the first non PHI/Label/Debug instruction. This patch adds a cache to save the last position for the sequence which has been checked in the previous call of SkipPHIsLabelsAndDebug. Differential Revision: https://reviews.llvm.org/D94981
2020-11-26[LiveDebugVariables] Strip all debug instructions from nodebug functionsRobert Lougher1-3/+3
A crash/assertion failure in the greedy register allocator was tracked down to a debug instr being passed to LiveIntervals::getInstructionIndex. Normally this should not occur as debug instructions are collected and removed by LiveDebugVariables before RA, and reinserted afterwards. However, when a function has no debug info, LiveDebugVariables simply strips any debug values that are present as they're not needed (this situation will occur when a function with debug info is inlined into a nodebug function). The problem is, it only removes DBG_VALUE instructions, leaving DBG_LABELs (the cause of the crash). This patch updates the LiveDebugVariables nodebug path to remove all debug instructions. The test case verifies that DBG_VALUE/DBG_LABEL instructions are present, and that they are stripped. When -experimental-debug-variable-locations is enabled, certain variable locations are represented by DBG_INSTR_REF instead of DBG_VALUE. The test case verifies that a DBG_INSTR_REF is emitted by the option, and that it is also stripped. Differential Revision: https://reviews.llvm.org/D92127
2020-10-22[DebugInstrRef] Pass DBG_INSTR_REFs through register allocationJeremy Morse1-0/+52
Both FastRegAlloc and LiveDebugVariables/greedy need to cope with DBG_INSTR_REFs. None of them actually need to take any action, other than passing DBG_INSTR_REFs through: variable location information doesn't refer to any registers at this stage. LiveDebugVariables stashes the instruction information in a tuple, then re-creates it later. This is only necessary as the register allocator doesn't expect to see any debug instructions while it's working. No equivalence classes or interval splitting is required at all! No changes are needed for the fast register allocator, as it just ignores debug instructions. The test added checks that both of them preserve DBG_INSTR_REFs. This also expands ScheduleDAGInstrs.cpp to treat DBG_INSTR_REFs the same as DBG_VALUEs when rescheduling instructions around. The current movement of DBG_VALUEs around is less than ideal, but it's not a regression to make DBG_INSTR_REFs subject to the same movement. Differential Revision: https://reviews.llvm.org/D85757
2020-09-17LiveDebugVariables.cpp - remove unnecessary Compiler.h include. NFCI.Simon Pilgrim1-1/+0
Already included in LiveDebugVariables.h
2020-09-16[NFC][Regalloc] accessors for 'reg' and 'weight'Mircea Trofin1-3/+3
Also renamed the fields to follow style guidelines. Accessors help with readability - weight mutation, in particular, is easier to follow this way. Differential Revision: https://reviews.llvm.org/D87725
2020-09-04[LiveDebugVariables] Delete unneeded doInitializationFangrui Song1-4/+0
2020-08-23[LiveDebugVariables] Internalize class DbgVariableValue. NFCFangrui Song1-0/+2
2020-06-30RegAlloc: Start using RegisterMatt Arsenault1-11/+11
2020-06-22[DebugInfo] Update MachineInstr to help support variadic DBG_VALUE instructionsstozer1-8/+9
Following on from this RFC[0] from a while back, this is the first patch towards implementing variadic debug values. This patch specifically adds a set of functions to MachineInstr for performing operations specific to debug values, and replacing uses of the more general functions where appropriate. The most prevalent of these is replacing getOperand(0) with getDebugOperand(0) for debug-value-specific code, as the operands corresponding to values will no longer be at index 0, but index 2 and upwards: getDebugOperand(x) == getOperand(x+2). Similar replacements have been added for the other operands, along with some helper functions to replace oft-repeated code and operate on a variable number of value operands. [0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139376.html<Paste> Differential Revision: https://reviews.llvm.org/D81852
2020-04-02[NFC] Fix performance issue in LiveDebugVariablesOCHyams1-35/+12
When compiling AMDGPUDisassembler.cpp in a stage 1 trunk build with CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_USE_SANITIZER=Address LiveDebugVariables accounts for 21.5% wall clock time. This fix reduces that to 1.2% by switching out a linked list lookup with a map lookup. Note that the linked list is still used to group UserValues by vreg. The vreg lookups don't cause any problems in this pathological case. This is the same idea as D68816, which was reverted, except that it is a less intrusive fix. Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D77226
2020-02-11[DebugInfo][NFC] Fixup the UserValue methods to use FragmentInfoOCHyams1-18/+19
Fixup the UserValue methods to use FragmentInfo instead of DIExpression because the DIExpression is only ever used to get the to get the FragmentInfo. The DIExpression is meaningless in the UserValue class because each definition point added to a UserValue may have a unique DIExpression. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74057
2020-02-11[DebugInfo][NFC] Rename the class DbgValueLocation to DbgVariableValueOCHyams1-87/+93
Rename the class DbgValueLocation to DbgVariableValue and instances from Loc to DbgValue. These names better express the new semantics introduced in D74053. The class previously represented a { Location } only. It now represents a { Location, DIExpression } pair which together describe a value. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74055
2020-02-11[DebugInfo] Teach LDV how to handle identical variable fragmentsOCHyams1-23/+37
LiveDebugVariables uses interval maps to explicitly represent DBG_VALUE intervals. DBG_VALUEs are filtered into an interval map based on their { Variable, DIExpression }. The interval map will coalesce adjacent entries that use the same { Location }. Under this model, DBG_VALUEs which refer to the same bits of the same variable will be filtered into different interval maps if they have different DIExpressions which means the original intervals will not be properly preserved. This patch fixes the problem by using { Variable, Fragment } to filter the DBG_VALUEs into maps, and coalesces adjacent entries iff they have the same { Location, DIExpression } pair. The solution is not perfect because we see the similar issues appear when partially overlapping fragments are encountered, but is far simpler than a complete solution (i.e. D70121). Fixes: pr41992, pr43957 Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74053
2020-02-06Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field"Jeremy Morse1-19/+33
This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06Revert "[SafeStack][DebugInfo] Insert DW_OP_deref in correct location"Jeremy Morse1-2/+2
This reverts commit 2d3174c4df6b5f4131346828d0a31675d80d6e2b. The overall solution for this problem is reverting D68945, which wasn't handling the -O0 path through the codegen backend correctly. See: discussion in D73526.
2020-02-04[DebugInfo] Re-instate LiveDebugVariables scope trimmingJeremy Morse1-1/+24
This patch reverts part of r362750 / D62650, which stopped LiveDebugVariables from trimming leading variable location ranges down to only covering those instructions that are in scope. I've observed some circumstances where the number of DBG_VALUEs in a function can be amplified in an un-necessary way, to cover more instructions that are out of scope, leading to very slow compile times. Trimming the range of instructions that the variables cover solves the slow compile times. The specific problem that r362750 tries to fix is addressed by the assignment to RStart that I've added. Any variable location that begins at the first instruction of a block will now be considered to begin at the start of the block. While these sound the same, the have different SlotIndexes, and the register allocator may shoehorn additional instructions in between the two. The test added in the past (wrong_debug_loc_after_regalloc.ll) still works with this modification. live-debug-variables.ll has a range trimmed to not cover the prologue of the function, while dbg-addr-dse.ll has a DBG_VALUE sink past one instruction with no DebugLoc, which is expected behaviour. Differential Revision: https://reviews.llvm.org/D73691
generated by cgit v1.1 at 2025-09-29 09:33:35 +0000