[pull] main from llvm:main - #1725
Merged
Merged
Conversation
printDwarfExpressionCompact has two pre-existing failure paths that silently produce bad output. The register-name callback is optional, but the short DW_OP_reg* and DW_OP_breg* paths call it directly, so a missing callback falls over. Use resolveRegName for every register form and report an unknown register only after both name-resolution paths fail. DW_OP_entry_value has the same problem: it ignores a failed recursive print, wraps the partial output in entry(...), and returns true. Print entry-value subexpressions into a temporary buffer and propagate failure before adding entry(...), so a failed subexpression can't come back as successful output. While here, GetRegName in llvm-objdump has a latent ordering issue: it writes an unknown-register diagnostic as soon as target lookup misses, even though resolveRegName can still decode an ASCII-packed virtual-register name. There's no natural in-tree input that hits this today -- LLVM emits text PTX and there's no NVPTX disassembler -- but a future out-of-tree disassembler using the same encoding would otherwise print a valid %r1 as "<unknown register 2454065>%r1". Keep GetRegName lookup-only and let the compact printer own the diagnostic. The llvm-objdump test makes the theoretical path testable by putting NVPTX's packed value for %r1 in ARM DWARF, so target lookup misses before packed-name decoding succeeds. Add target-independent unit coverage for missing callbacks, unknown registers, and nested failures. Tested via make check. Assisted by AI.
…C properties (#212633) When accessing Objective-C properties via dot-notation (e.g., obj.foo), include-cleaner was previously only recording the usage of the property itself or its underlying getter/setter methods. This could lead to cases where the header declaring the receiver's type (Interface or Protocol) was incorrectly flagged as unused if no other standard methods were invoked on it.
I just merged #204067 and unfortunately forgot to locally compile all the PTX I was generating from cache hint metadata in lit tests. - I didn't know that .L2::cache_hint isn't valid on PTX volatile loads. We need to drop the metadata then for volatile loads. I'll put this up in a PR later, but for now just delete the lit test that generates the invalid PTX. I'll add it back in the follow up. - I forgot to provide SM version and PTX version when invoking ptxas for the lit tests.
…efs (#211397) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the initial straight rename commit. It will probably break the docs build, but it has to be a separate PR for blame preservation purposes. --------- Co-authored-by: owenca <owenpiano@gmail.com>
# Motiviation
Currently, if one wants to know the size of the sections in a gSYM (e.g.
to check if they exceed 4GB), they have to dump the whole gSYM in the
text form, then process that huge text to get the sizes.
# New option `--statistics[=<format>]`
This patch adds a `llvm-gsymutil --statistics[=<format>]` option to
print the size info for all sections. It supports three formats:
* `text`: Default.
* `json`: Dense JSON.
* `pretty-json`: Pretty-printed JSON.
See example output below.
# Examples
```
royshi-mac-office ~/tmp % guuu v2.gsym --statistics
GSYM statistics for "v2.gsym":
UUID: 4C4C446A-5555-3144-A1CF-AEBBCCD48E61
Number of addresses: 6,382
File size: 3,095,960 bytes
Header: 20 bytes ( 0.00%)
Global data dir: 140 bytes ( 0.00%)
UUID section: 16 bytes ( 0.00%)
Address table: 25,528 bytes ( 0.82%)
Addr info offsets: 51,056 bytes ( 1.65%)
File table: 3,652 bytes ( 0.12%)
String table: 1,772,169 bytes (57.24%)
Function info data: 1,243,376 bytes (40.16%)
Size and name: 76,584 bytes ( 2.47%)
Line table info: 145,260 bytes ( 4.69%)
Inline info: 58,540 bytes ( 1.89%)
Call site info: 25,902 bytes ( 0.84%)
End of list: 51,056 bytes ( 1.65%)
Padding: 5,387 bytes ( 0.17%)
Merged func info: 880,647 bytes (28.45%)
InfoType/InfoLength/Count/FnSize: 102,900 bytes ( 3.32%)
Size and name: 209,160 bytes ( 6.76%)
Line table info: 424,847 bytes (13.72%)
Inline info: 2,058 bytes ( 0.07%)
Call site info: 2,242 bytes ( 0.07%)
Merged func info: 0 bytes ( 0.00%)
End of list: 139,440 bytes ( 4.50%)
Padding: 3 bytes ( 0.00%)
royshi-mac-office ~/tmp % guuu v2.gsym --statistics=pretty-json
{
"byte-sizes": {
"addr_info_offsets": 51056,
"address_table": 25528,
"file_size": 3095960,
"file_table": 3652,
"function_info_data": 1243376,
"function_info_type_sizes": {
"call_site_info": 25902,
"end_of_list": 51056,
"inline_info": 58540,
"line_table_info": 145260,
"merged_func_info": 880647,
"merged_func_info_type_sizes": {
"call_site_info": 2242,
"end_of_list": 139440,
"infotype_infolength_count_and_fnsize": 102900,
"inline_info": 2058,
"line_table_info": 424847,
"merged_func_info": 0,
"size_and_name": 209160
},
"padding": 5387,
"size_and_name": 76584
},
"global_data_directory": 140,
"header": 20,
"padding": 3,
"string_table": 1772169,
"uuid_section": 16
},
"num_addresses": 6382,
"path": "v2.gsym",
"uuid": "4C4C446A-5555-3144-A1CF-AEBBCCD48E61"
}
```
…214544) The isel patterns lowering `fptrunc (fmul float %a, %b)` to a mix instruction passed +0.0 as the FMA addend. Under round-to-nearest fma(a, b, +0.0) is +0.0 whenever a * b is -0.0, so the sign of zero was lost: on gfx90a, `(half)(-1.0f * 0.0f)` returned +0.0. Use a -0.0 addend instead, which is the correct multiplicative identity for an FMA and is what the f32 sibling pattern in MadFmaMixFP32Pats has always done. Verified on gfx90a: (half)(-1.0f * 0.0f) now returns 0x8000.
…3310) isFMADLegal and isFMAFasterThanFMulAndFAdd read the denormal mode out of the MachineFunction, so nothing before instruction selection can ask them whether an fmul/fadd pair will be fused. Take an explicit DenormalFPEnv instead, and make the existing MachineFunction / SelectionDAG / MachineInstr entry points thin wrappers over it. Also override the IR level isFMAFasterThanFMulAndFAdd hook. The two views agree by construction, since SIModeRegisterDefaults copies its denormal fields out of getDenormalFPEnv. isFMADLegal uses VT as written and does not look through vectors, so a vector type reports false, as in the SelectionDAG overload it was extracted from. The patch is preparation for querying these from getArithmeticInstrCost and a revived isProfitableToSinkOperands. Contributes to #211092 Assisted-By: Claude Opus 5
…header PHIs" (#212485) Reverts #201572 Multiple miscompilations are reported, see #207744, #212027 That commit made forgetLoop() rely on LoopUsers[L] and stop walking the def-use chain of the loop-header PHIs. This is insufficient, because some cached data is derived from the underlying IR of SCEVUnknown, it is not reachable from LoopUsers[L]. After that commit, forgetLoop() no longer invalidated them, so stale UnsignedRanges / SignedRanges, ConstantMultipleCache, ValuesAtScopes cause miscompilations.
…#213614) This changes `isExtractSubvectorCheap` into `getExtractSubvectorCost`. This is preparing for #201056 in order to remove `isNarrowingProfitable` bail out for `narrowInsertExtractVectorBinOp`. The reason is `isNarrowingProfitable` should be applying on scalar variable instead of vectors. --------- Co-authored-by: shore <shorshen@amd.com>
…211398) Tracking issue: #201242 See the [migration guide] for more information. This is a stacked PR based on #211397 , which will be a standalone commit that renames *.rst -> *.md before this PR lands for history preservation purposes. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines First, the generator was updated to generate markdown constructs, and then the Doxygen comments in `Format.h` and `IncludeStyle.h` were also modified to use markdown constructs. Mostly this means using single backticks instead of double backticks, which is the Doxygen-native way of expressing code font blocks anyway, so that's good. To validate, I built the Sphinx docs and the doxygen, and I confirmed that the generator script is idempotent, meaning it doesn't change the markdown output. When I add a new option to clang-format, it shows up in the help text block, so it works.
In some configurations, BOLT runtime libraries may be built as thin archive. Use the more generic `Archive::create` to handle these.
…214168) A non-atomic volatile access on AMDGPU includes store-available or load-visible semantics at the widest scope supported by its address space: - system scope for global/generic, - workgroup scope for local (LDS) An atomic volatile access has the same availability and visibility as its atomic non-volatile variant. Previous Reference: 2f499b9 This fully specifies the behavior that the LLVM memory model leaves target-dependent, matching the implementation in SIMemoryLegalizer. Assisted-By: Claude Opus 4.8
Apply expression-specific floating-point options when emitting fneg and call instructions. This prevents these instructions from retaining fast-math flags disabled by local FP pragmas, such as #pragma clang fp reassociate(off). Fixes #51905
…out FP vector support (#183158) Fixes #182047 **Issue:** Compiling floating-point vector selects (e.g., `<2 x float>`) on RISC-V targets that only support integer vectors (like `zve32x`) causes a compiler crash in the Loop Vectorizer (`emitInvalidCostRemarks` unhandled `TypeSwitch`). **Root Cause:** The Type Legalizer correctly scalarizes the unsupported FP vector into `f32` operations. However, `RISCVTTIImpl::getCmpSelInstrCost` attempted to cost `Instruction::Select` natively without verifying floating-point vector hardware support. It passed the scalarized type to `getRISCVInstructionCost` to price a native vector merge instruction, which returned `InstructionCost::getInvalid()`. **Fix:** Added hardware support checks (`hasVInstructionsF16/32/64()`) for floating-point types in the `Instruction::Select` block. If the target lacks the required instructions, it falls back to `BaseT::getCmpSelInstrCost` to correctly calculate the sequential scalarized cost, allowing the vectorizer to safely bail out. **Testing:** * Added `llvm/test/Analysis/CostModel/RISCV/select-fp-zve32x.ll` * Verified expected scalarized costs using `update_analyze_test_checks.py` Co-authored-by: Luke Lau <luke@igalia.com>
Add patterns to select VPICKVE2GR_BU/HU and [X]VPICKVE2GR_WU for vector extraction followed by zero extension, eliminating redundant masking instructions.
After clauses are formed their internal loads can be reordered to facilitate some additional opportunities for overlapping computation. This late stage rescheduling causes no change in register pressure.
The libhipcxx test checks the include paths produced by the driver. It also ran a HIP device compilation, which requires the AMDGPU target and fails in builds that do not enable it. Remove the compilation and keep the driver command checks enabled in all builds. Buildbot failure: https://lab.llvm.org/buildbot/#/builders/225/builds/14729
This patch adds an initial scheduler model for the XiangShan KunMingHu microarchitecture in the RISC-V backend, covering scalar instructions only. Support for vector instructions is not included in this patch. The model includes initial ProcResource definitions and WriteRes mappings for scalar instructions, derived from the publicly available XiangShan KunMingHu documentations: * [XiangShan Docs](https://docs.xiangshan.cc/projects/design/en/latest/). * [XiangShan User Guide](https://docs.xiangshan.cc/projects/user-guide/en/latest/). * [XiangShan KunMingHu RTL](https://github.com/OpenXiangShan/XiangShan). Simulator-based validation results will be provided in a follow-up update. Measurement results from real hardware will also be added afterwards to further validate and refine the model if necessary. This implementation was contributed by the [XSCC Team](https://github.com/orgs/OpenXiangShan/teams/xscc). --------- Co-authored-by: Chyaka <lilium23187@gmail.com> Co-authored-by: Bhe6669 <hebo@bosc.ac.cn> Co-authored-by: Tang Haojin <tanghaojin@outlook.com> Co-authored-by: buggfg <wangyingying@bosc.ac.cn>
…C) (#214630) Both collections were initialized with a check-then-set on a null pointer, which is race-y. We can achieve the same thing by initializing the pointer with the allocation, while retaining the leak.
Add legalizer rules so `llvm.lround/llround` lower to`
fcvt.{w,l}.{h,s,d}` with FRM_RMM.
This will allow for tools like clang/flang/llc to default to the NewPM for targets that request it. Future patches will update clang/llc and flip it for targets that have been fully ported but shouldn't have a large blast radius (like Lanai and MSP430). Pursuant to https://discourse.llvm.org/t/rfc-incrementally-enabling-the-newpm-for-codegen/91410/11. Reviewers: arsenm, vikramRH, aengelke Pull Request: #214570
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )