forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 4
[AutoBump] Merge with 412e1af1 (Dec 20) (25) [Only tested MLIR] #495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
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
The default legalization uses vmslt with a vector of XLen to compute a mask. This doesn't work if the type isn't legal. For fixed vectors it will scalarize. For scalable vectors it crashes the compiler. This patch uses an alternate strategy that promotes the i1 vector to an i8 vector and does the merge. I don't claim this to be the best lowering. I wrote it quickly almost 3 years ago when a crash was reported in our downstream. Fixes llvm#120405.
The tautological bounds check warning added in llvm#120222 does not take into account whether signed integer overflow is well defined or not, which could result in a developer removing a bounds check that may not actually be always false because of different overflow semantics. ```c int check(const int* foo, unsigned int idx) { return foo + idx < foo; } ``` ``` $ clang -O2 -c test.c test.c:3:19: warning: pointer comparison always evaluates to false [-Wtautological-compare] 3 | return foo + idx < foo; | ^ 1 warning generated. # Bounds check is eliminated without -fwrapv, warning was correct $ llvm-objdump -dr test.o ... 0000000000000000 <check>: 0: 31 c0 xorl %eax, %eax 2: c3 retq ``` ``` $ clang -O2 -fwrapv -c test.c test.c:3:19: warning: pointer comparison always evaluates to false [-Wtautological-compare] 3 | return foo + idx < foo; | ^ 1 warning generated. # Bounds check remains, warning was wrong $ llvm-objdump -dr test.o 0000000000000000 <check>: 0: 89 f0 movl %esi, %eax 2: 48 8d 0c 87 leaq (%rdi,%rax,4), %rcx 6: 31 c0 xorl %eax, %eax 8: 48 39 f9 cmpq %rdi, %rcx b: 0f 92 c0 setb %al e: c3 retq ```
The ScopedHashTable class is particularly used to develop string tables for parsers and code convertors. For instance, the MLIRGen class from the toy example for MLIR actively uses this class to define scopes for declared variables. To demonstrate common use cases for the ScopedHashTable class as well as to check its behavior in different situations, the unittest has been added. Signed-off-by: Pavel Samolysov <samolisov@gmail.com>
This patch fixes warnings of the form: llvm/unittests/ADT/ScopedHashTableTest.cpp:41:20: error: 'ScopedHashTableScope' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
This function is most often used in range based loops or algorithms where the iterator is implicitly dereferenced. The dereference returns an SDNode * of the user rather than SDUse * so users() is a better name. I've long beeen annoyed that we can't write a range based loop over SDUse when we need getOperandNo. I plan to rename use_iterator to user_iterator and add a use_iterator that returns SDUse& on dereference. This will make it more like IR.
…ter attribs (llvm#117183) ByVal arguments and Swifterror require special handling in the coroutine passes. The goal of this section is to provide a description of how these parameter attributes are handled.
This patch adds basic support of `MachinePipeliner` and disable
it by default.
The functionality should be OK and all llvm-test-suite tests have
passed.
…acks (llvm#120380) CheckParameterPacksForExpansion() previously assumed that template arguments don't include PackExpansion types when attempting another pack expansion (i.e. when NumExpansions is present). However, this assumption doesn't hold for type aliases, whose substitution might involve unexpanded packs. This can lead to incorrect diagnostics during substitution because the pack size is not yet determined. To address this, this patch calculates the minimum pack size (ignoring unexpanded PackExpansionTypes) and compares it to the previously expanded size. If the minimum pack size is smaller, then there's still a chance for future substitution to expand it to a correct size, so we don't diagnose it too eagerly. Fixes llvm#61415 Fixes llvm#32252 Fixes llvm#17042
…etGluedUser. NFC (llvm#120512)
…vm#120509) Most of these are just places that want the first user and aren't iterating over the whole list. While there I changed some use_size() == 1 to hasOneUse() which is more efficient. This is part of an effort to rename use_iterator to user_iterator and provide a use_iterator that dereferences to SDUse&. This patch helps reduce the diff on later patches.
AsmParser will call initSection unless -n is specified. It is not good to call initSection twice.
This is done because the CodeGen library and Passes library both link against Analysis, to avoid adding a dependency between CodeGen and Passes if we want to extend the DroppedVariableStats code for MIR stats as well, as seen in llvm#120501
Nowadays yonghong-song and eddyz87 are more involved with LLVM BPF development than 4ast, so update the maintainer list to reflect this.
…llvm#120425) Bigcheese isn't actively working on Windows support in object tools anymore, so move him to the inactive maintainer list. I'm also not aware of anyone else who is actively involved in this area currently, so I'm dropping the category entirely for now.
We currently list jakehehrlich as the maintainer for llvm-objcopy / ObjCopy, but he hasn't been involved with LLVM for more than 5 years. Convert the llvm-object category into a broader binary utilities category and add jh7370 and MaskRay as the new maintainers.
Reland "Add a pass to collect dropped var stats for MIR" (llvm#117044) I am trying to reland llvm#115566 I also moved the DroppedVariableStats code to the Analysis lib This is part of a stack of patches with llvm#120502 being the first one in the stack
This reverts commit 223c764. Reverted due to vuildbot failure: flang-aarch64-libcxx Linking CXX shared library lib/libLLVMAnalysis.so.20.0git FAILED: lib/libLLVMAnalysis.so.20.0git
Nominate dwblaikie and kuhar as new maintainers for ADT/Support, replacing chandlerc.
Reverts llvm#119885 llvm-project/llvm/lib/Target/RISCV/RISCVSchedMIPSP8700.td:20:5: error: Processor does not define resources for WriteFCvtF32ToF16 def MIPSP8700Model : SchedMachineModel {
This commit ensures the validation pass is not run on operations from other dialects. In doing so, operations from other dialects that, for example, use types not supported by TOSA don't result in an error. Signed-off-by: Luke Hutton <luke.hutton@arm.com>
…llvm#120538) Reland without item 2 from llvm#120370 to avoid breaking libc++ tests. This reverts commit 60a2f32.
…vm#120449) Re-write the sema and codegen for the atomic_test_and_set and atomic_clear builtin functions to go via AtomicExpr, like the other atomic builtins do. This simplifies the code, because AtomicExpr already handles things like generating code for to dynamically select the memory ordering, which was duplicated for these builtins. This also fixes a few crash bugs, one when passing an integer to the pointer argument, and one when using an array. This also adds diagnostics for the memory orderings which are not valid for atomic_clear according to https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html, which were missing before. Fixes llvm#111293.
…vm#120459) This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. llvm#101657 The complete changes for porting are present in this draft PR: llvm#102601 Added clang-format changes for ProcessLauncherPosixFork.cpp which will be followed by ptrace changes in: - llvm#120390
…usReg (llvm#119865) ZPR2StridedOrContiguous loads used by a FORM_TRANSPOSED_REG_TUPLE pseudo should attempt to assign a strided register to avoid unnecessary copies, even though this may overlap with the list of SVE callee-saved registers.
Support the following relocations and assembly operators: - `R_AARCH64_AUTH_TLSDESC_ADR_PAGE21` (`:tlsdesc_auth:` for `adrp`) - `R_AARCH64_AUTH_TLSDESC_LD64_LO12` (`:tlsdesc_auth_lo12:` for `ldr`) - `R_AARCH64_AUTH_TLSDESC_ADD_LO12` (`:tlsdesc_auth_lo12:` for `add`)
…r of bools (llvm#118186) Fixes llvm#116932 - Remove the quotation marks in the diagnostic message for err_ext_vector_component_name_illegal - Pass in the quotation marks directly when reporting an illegal vector component name inside `CheckExtVectorComponent` - Add an offset to the `OpLoc` passed into `S.Diag` so the error message arrow points directly to the offending illegal component rather than to the '.' at the start of the component identifier. - Modify the `vector-bool.cpp` element-wise access test case so it (correctly) now only expects a single set of quotes.
Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes llvm#70982. This commit changes the way how `func.func` ops are lowered to LLVM. Previously, the signature of the entire region (i.e., entry block and all other blocks in the `func.func` op) was converted as part of the `func.func` lowering pattern. Now, only the entry block is converted. The remaining block signatures are converted together with `cf.br` and `cf.cond_br` as part of `cf-to-llvm`. All unstructured control flow is not converted as part of a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with unstructured control flow. Also add more test cases for control flow dialect ops. Note: This PR is in preparation of llvm#120431, which adds an additional GPU-specific lowering for `cf.assert`. This was a problem because `cf.assert` used to be converted as part of `func-to-llvm`. Note for LLVM integration: If you see failures, add `-convert-cf-to-llvm` to your pass pipeline.
> See [developer policy](https://llvm.org/docs/DeveloperPolicy.html#maintainers) for context on the maintainers terminology. We currently list @majnemer as the maintainer for InstCombine. While David does still occasionally contribute in this area, most of the contributions/reviews come from other people nowadays. I'd like to propose @dtcxzyw and myself as the new maintainers for this area. I've also expanded it to include InstSimplify and ValueTracking, and these tend to all go together.
Co-authored-by: yavtuk <yavtuk@ya.ru>
This commit should have been part of llvm#120580.
`R2` should be always greater than `R1` here because both `R1` and `R2` are not modified inside the loop.
…ng-conversions (llvm#111510) (llvm#118209) This PR improves the docs for this check to include an example of hidden narrowing conversions from the integer promotion rules in arithmetic.
…ch + cost-comparison Helps with debugging to show to that the fold found the match, and shows the old + new costs to indicate whether the fold was/wasn't profitable.
…ssage to help finding vectorcombine stages in the debug log
…ed (llvm#120102) This is part 1 of caching for smart pointer accessors, building on top of the CachedConstAccessorsLattice, which caches "normal" accessors. Smart pointer accessors are a bit different in that they may: - have aliases to access the same underlying data (but potentially returning slightly different types like `&` vs `*`). Within a "checked" sequence users may mix uses of the different aliases and the check should apply to any of the spellings. - may have non-const overloads in addition to the const version, where the non-const doesn't actually modify the container Part 2 will follow and add transfer functions utilities. It will also add a user UncheckedOptionalAccessModel. We'd seen false positives when nesting StatusOr<optional<T>> and optional<StatusOr<T>>, etc. which this can help address.
This PR is motivated by a mismatch we discovered between compilation results with vs. without `-g3`. We noticed this when compiling SPEC2017 testcases. The specific instance we saw is fixed in this PR by modifying a guard (see below), but it is likely similar instances exist elsewhere in the codebase. The specific case fixed in this PR manifests itself in the `SimplifyCFG` pass doing different things depending on whether DebugInfo is generated or not. At the end of this comment, there is reduced example code that shows the behavior in question. The differing behavior has two root causes: 1. Commit llvm@c07e19b adds loop metadata including debug locations to loops that otherwise would not have loop metadata 2. Commit llvm@ac28efa6c100 adds a guard to a simplification action in `SImplifyCFG` that prevents it from simplifying away loop metadata So, the change in 2. does not consider that when compiling with debug symbols, loops that otherwise would not have metadata that needs preserving, now have debug locations in their loop metadata. Thus, with `-g3`, `SimplifyCFG` behaves differently than without it. The larger issue is that while debug info is not supposed to influence the final compilation result, commits like 1. blur the line between what is and is not debug info, and not all optimization passes account for this. This PR does not address that and rather just modifies this particular guard in order to restore equivalent behavior between debug and non-debug builds in this one instance. --- Here is a reduced version of a file from `f526.blender_r` that showcases the behavior in question: ```C struct LinkNode; typedef struct LinkNode { struct LinkNode *next; void *link; } LinkNode; void do_projectpaint_thread_ph_v_state() { int *ps = do_projectpaint_thread_ph_v_state; LinkNode *node; while (do_projectpaint_thread_ph_v_state) for (node = ps; node; node = node->next) ; } ``` Compiling this with and without DebugInfo, and then disassembling the results, leads to different outcomes (tested on SystemZ and X86). The reason for this is that the `SimplifyCFG` pass does different things in either case.
`llvm::Error` must be consumed, otherwise it will cause trap during destructor
…20442) When assumptions are present `Terms.size()` does not actually count the number of conditions collected from dominating branches; introduce a separate counter. Fixes llvm#120237
…allthrough (llvm#120739) Missed when changing code in llvm#120102
… the instruction folding order.
This fixes some regressions from recent changes to vector combine in llvm#120216. It allows shuffleToIdentity to look through fp casts as other casts, and makes sure mismatching vector types in splats and casts do not block the transform, as only the lanes should matter.
llvm#120738) I've only fixed up the tests where I was able to use a simple sed script to replace the text. Even after this patch lands, there are still over 50 tests that need updating in X86/CostModel!
1. We can use `getNumElements()` only for memrefs with trivial layout. 2. Buffer ops expecting sizes in i32 but descriptor values can be either i32 or i64, add appropriate casts. This implementation is not ideal as it can overflow, but it's still better than generating broken IR.
This commit should have been part of llvm#120580.
The code was asserting because allowsMemoryAccess() was called with Extended Value Type INVALID_SIMPLE_VALUE_TYPE in HexagonISelLowering.cpp. Fixes llvm#118881
…llvm#120059) The specification of these routines can be found here: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines
Objective:
- Provide a common framework in LLVM for collecting various usage
metrics
- Characteristics:
- Extensible and configurable by:
- tools in LLVM that want to use it
- vendors in their downstream codebase
- tools users (as allowed by vendor)
Background:
The framework was originally proposed only for LLDB, but there were
quite a few requests to move it to llvm/lib given telemetry
is a common use case in a lot of tools, not just LLDB.
See more details on the design and discussions here on the RFC:
https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588/20?u=oontvoo
---------
Co-authored-by: Alina Sbirlea <alina.g.simion@gmail.com>
Co-authored-by: James Henderson <James.Henderson@sony.com>
Co-authored-by: Pavel Labath <pavel@labath.sk>
Reverts llvm#100769 A bug in the lowering (the subtraction should be reversed) was found after merging and it will all be replaced by llvm#117007 anyway.
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.