Update LLVM version to 189d4711915f#561
Merged
konstantinschwarz merged 1119 commits intoaie-publicfrom Jul 22, 2025
Merged
Conversation
…neType (#91422)
Extend `DIBasicType` and `DISubroutineType` with additional field
`annotations`, e.g. as below:
```
!5 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed, annotations: !6)
!6 = !{!7}
!7 = !{!"btf:type_tag", !"tag1"}
```
The field would be used by BPF backend to generate DWARF attributes
corresponding to `btf_type_tag` type attributes, e.g.:
```
0x00000029: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)
0x0000002d: DW_TAG_LLVM_annotation
DW_AT_name ("btf:type_tag")
DW_AT_const_value ("tag1")
```
Such DWARF entries would be used to generate BTF definitions by tools
like [pahole](https://github.com/acmel/dwarves).
Note: similar fields with similar purposes are already present in
DIDerivedType and DICompositeType.
Currently "btf_type_tag" attributes are represented in debug information
as 'annotations' fields in DIDerivedType with DW_TAG_pointer_type tag.
The annotation on a pointer corresponds to pointee having the attributes
in the final BTF.
The discussion in
[thread](https://lore.kernel.org/bpf/87r0w9jjoq.fsf@oracle.com/) came to
conclusion, that such annotations should apply to the annotated type
itself. Hence the necessity to extend `DIBasicType` & `DISubroutineType`
types with 'annotations' field to represent cases like below:
```
int __attribute__((btf_type_tag("foo"))) bar;
```
This was previously tracked as differential revision:
https://reviews.llvm.org/D143966
The DIBuilder C API was changed to deal with DbgRecord functions: llvm/llvm-project#84915 llvm/llvm-project#85657 llvm/llvm-project#92417 (comment) As discussed by @nikic and @OCHyams: llvm/llvm-project#92417 (comment) > For the intrinsic-inserting functions, do you think we should: > > a) mark as deprecated but otherwise leave them alone for now. > b) mark as deprecated and change their behaviour so that they > do nothing and return nullptr. > c) outright delete them (it sounds like you're voting this one, > but just wanted to double check). This patch implements option (c).
…odifiable" (#95833) Reverts llvm/llvm-project#94159 @zygoloid had some concerns about the implementation of this, which make sense to me, so I’d like to revert this for now so we can have more time to think about how to best approach this (if at all...)
This change keeps existing behavior, namely that if we hit a Z3 timeout we will accept the report as "satisfiable". This prepares for the commit "Harden safeguards for Z3 query times". https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520 Reviewers: NagyDonat, haoNoQ, Xazax-hun, mikhailramalho, Szelethus Reviewed By: NagyDonat Pull Request: llvm/llvm-project#95128
This patch is a functional change. https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520 As a result of this patch, individual Z3 queries in refutation will be bound by 300ms. Every report equivalence class will be processed in at most 1 second. The heuristic should have only really marginal observable impact - except for the cases when we had big report eqclasses with long-running (15s) Z3 queries, where previously CSA effectively halted. After this patch, CSA will tackle such extreme cases as well. Reviewers: NagyDonat, haoNoQ, Xazax-hun, Szelethus, mikhailramalho Reviewed By: NagyDonat Pull Request: llvm/llvm-project#95129
For better dominance check inside the function.
The Legacy PM was deprecated for the optimization pipeline in LLVM 14 [1] (the support was removed altogether in the following release). This patch removes the original Hello example that was introduced to illustrate the Legacy PM. The Hello example no longer works and hence is deleted. The corresponding documentation is also removed. Note, Hello example for the new PM is located in * llvm/lib/Transforms/Utils/HelloWorld.cpp and documented in * WritingAnLLVMNewPMPass.rst. [1] https://releases.llvm.org/14.0.0/docs/ReleaseNotes.html#changes-to-the-llvm-ir
… for SVE (#95236) This patch adds support for legal SVE fromal arguments in IRTranslator, and support for COPY with SVE. SVE arguments are allowed only if the hidden option `-aarch64-enable-gisel-sve` is enabled. Illegal types and predicates like `nxv8i1` are not supported yet.
…(#93529) Extends bubble-up pack through reshape pattern to handle pack propagation through expand shape ops. --------- Co-authored-by: Prashant Kumar <pk5561@gmail.com>
/llvm-project/llvm/tools/llvm-c-test/llvm-c-test.h:39:24:
error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int llvm_test_dibuilder();
^
void
1 error generated.
These produce garbage libcalls, so the result is not useful but this at least shows we don't assert.
…x (#95591) The global/flat/buffer atomic fmin/fmax situation is a mess. These instructions have been renamed 3 times. We currently have separate pseudos defined for the same opcodes with the different names (e.g. GLOBAL_ATOMIC_MIN_F64 from gfx90a and GLOBAL_ATOMIC_FMIN_X2 from gfx10). Use the _FMIN versions as the canonical name for the f32 versions. Use the _MIN_F64 style as the canonical name for the f64 case. This is because gfx90a has the most sensible names, but does not have the f32 versions.t sho Wire through the pseudo to use for the instruction properties vs. the assembly name like in other cases. This will simplify handling of direct atomicrmw selection. This will simplify directly selecting these from atomicrmw.
…#95730) See the comment: llvm/llvm-project#92083 (comment) After the patch, llvm/llvm-project#92083, the lower 32 bits of DeclID can be the same commonly. This may produce many collisions. It will be best to change the default hash implementation for uint64_t. But sent this one as a quick workaround. Feel free to update this if you prefer other hash functions.
These were required a long time ago due to `static_assert` not actually being available in C++03. Now `static_assert` is simply mapped to `_Static_assert` in C++03, making the additional parens unnecessary.
Differential Revision: https://reviews.llvm.org/D121213
This changes the `is_swappable` implementation to use variable templates first and basing the class templates on that. This avoids instantiating them when the `_v` versions are used, which are generally less resource intensive.
This is a follow up to #92037, which moved the architecture information. Generate the AArch64TargetParser CPUInfo from tablegen Processor defs using a new tablegen emitter. Some basic error checking is added in the emitter to ensure that duplicate features are not added to the Processor defs. The generic CPU becomes an entry in tablegen. Some CPU features which were present in the CPUInfo but absent from the tablegen defs have been added to tablegen. FeatureCrypto is replaced with FeatureSHA2 and FeatureAES. This changes a few of the tests.
…VLI. NFC SlotIndexes is already marked as a transitive requirement of LiveIntervals, so we don't need to specify it again in RISCVInsertVSETVLI.
For x86_64 callable functions, ARM64EC requires an entry thunk generated by the compiler. The linker interprets .hybmp sections to associate function chunks with their entry points and writes an offset to thunks preceding function section contents. Additionally, ICF needs to be aware of entry thunks to not consider chunks to be equal when they have different entry thunks, and GC needs to mark entry thunks together with function chunks. I used a new SectionChunkEC class instead of storing entry thunks in SectionChunk, following the guideline to keep SectionChunk as compact as possible. This way, there is no memory usage increase on non-EC targets.
This patch removes the TPIDR2 lazy-save object and buffer if no lazy save is required. --------- Co-authored-by: Samuel Tebbs <samuel.tebbs@arm.com>
These are incorrectly matching with signed offsets.
The runtime API for copy-in copy-out currently only has an entry only for the copy-out. This entry has a "skipInit" boolean that is never set to false by lowering and it does not deal with the deallocation of the temporary. The generated code was a mix of inline code and runtime calls This is not a big deal, but this is unneeded compiler and generated code complexity. With assumed-rank, it is also more cumbersome to establish a temporary descriptor. Instead, this patch: - Adds a CopyInAssignment API that deals with establishing the temporary descriptor and does the copy. - Removes unused arg to CopyOutAssign, and pushes destruction/deallocation responsibility inside it. Note that this runtime API are still not responsible for deciding the need of copying-in and out. This is kept as a separate runtime call to IsContiguous, which is easier to inline/replace by inline code with the hope of removing the copy-in/out calls after user function inlining. @vzakhari has already shown that always inlining all the copy part increase Fortran compilation time due to loop optimization attempts for loops that are known to have little optimization profitability (the variable being copied from and to is not contiguous).
Pulled from #82290
Fixes some atomicrmw fadd and intrinsic cases
Because of the --debug-only flag.
Share the implementation with the current interpreter.
…055) This fixes llvm/llvm-project#93309, and seems to match how GNU ld handles this case.
There are only three actual uses of the section kind in MCSection: isText(), XCOFF, and WebAssembly. Store isText() in the MCSection, and store other info in the actual section variants where required. ELF and COFF flags also encode all relevant information, so for these two section variants, remove the SectionKind parameter entirely. This allows to remove the string switch (which is unnecessary and inaccurate) from createELFSectionImpl. This was introduced in [D133456](https://reviews.llvm.org/D133456), but apparently, it was never hit for non-writable sections anyway and the resulting kind was never used.
Reverts the behavior introduced by 770393b while keeping the refactored code. Fixes a miscompile on AArch64, at the cost of a small regression on AMDGPU. #96146 opened to investigate the issue
konstantinschwarz
requested review from
F-Stuckmann,
SagarMaheshwari99,
abhinay-anubola,
abnikant,
andcarminati,
katerynamuts,
khallouh,
martien-de-jong,
niwinanto and
stephenneuendorffer
as code owners
isoard-amd
force-pushed
the
kschwarz.llvm.bump
branch
from
88e1b12 to
e63eb3a
Compare
isoard-amd
force-pushed
the
kschwarz.llvm.bump
branch
from
e63eb3a to
970f692
Compare
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.