merge develop #10
Closed
merge develop #10
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
shuffle (cast X), (cast Y), Mask --> cast (shuffle X, Y, Mask) This extends the transform added with 0353c2c. If the shuffle reduces vector length, the transform reduces the width of the cast, so that should be a win for most codegen (if not, it can be inverted).
The crash is caused by incorrect order set by reorderBottomToTop(), which happens when it is reordering a TreeEntry which has a user that has already been reordered earlier. Please see the detailed description in the lit test. Differential Revision: https://reviews.llvm.org/D126099
Semantics was allowing calls to CHARACTER(*) functions, which are odd things -- they can be declared, and passed around, but can never actually be called as such. They must be redeclared with an explicit length that ends up being passed as a hidden argument. So check for these calls and diagnose them, add tests, and clean up some existing tests that were in error and now get caught. Possible TODO for lowering: there were some test cases that used bad calls to assumed-length CHARACTER*(*) functions and validated their implementations. I've removed some, and adjusted another, but the code that somehow implemented these calls may need to be removed and replaced with an assert about bad semantics. Differential Revision: https://reviews.llvm.org/D126148
…urce files This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816) Performed a global search/replace as in title against LLVM sources Differential Revision: https://reviews.llvm.org/D126263
…ional to size of CFG. Currently, the maximum number of iterations of the loop for finding the fixpoint of the dataflow analysis is set at 2^16. When things go wrong in an analysis, this can be far too large. This patch changes the limit to be proportional to the size of the CFG, which will generally be far smaller than 2^16 (while still maintaining 2^16 as the absolute limit). Differential Revision: https://reviews.llvm.org/D126316
Name resolution for subprograms checks whether the name is already present in the enclosing scope as a generic interface, so that the case of a generic with the same name as one of its specifics can be handled. The particular means by which the enclosing scope is searched for the name would resolve the name (bind a symbol to it) as a side effect. This turns out to be the wrong thing to do when the subprogram is going to have its symbol created in another scope to cope with its BIND(C,NAME="name") name, and its Fortran name is already present in the enclosing scope for a subprogram of the same name but without BIND(C,NAME="name"). A very long explanation for a one-line fix, sorry. In short, change the code to look up the name but not resolve it at that point. Differential Revision: https://reviews.llvm.org/D126149
These tests are failing on the PPC64 AIX CI bot, but it's unclear why, as they pass on other CI jobs. I marked them as unsupported on AIX for now while investigating the failure.
The purity or impurity of a call to a generic interface depends on the attributes of the specific procedure or specific binding. Change expression analysis of calls to generic interfaces to replace the symbol in the parse tree with the specific procedure or binding; this ensures that later checking for purity in DO CONCURRENT and other contexts will be accurate. Remove an "XFAIL" from a test that now passes again with this fix. Differential Revision: https://reviews.llvm.org/D126150
A utility predicate in semantics was incorrectly determining that an INTERFACE ASSIGNMENT(=) (or other form of generic) could not have a specific procedure with an unlimited polymorphic second argument. This led to a crash later in expression analysis. Fix, and extend tests. Differential Revision: https://reviews.llvm.org/D126151
User-defined derived type I/O subroutines need to be unique for a given type and operation in any scope, but it is acceptable to have more than one defined I/O subroutine so long as only one of them is visible. Differential Revision: https://reviews.llvm.org/D126152
Ignore `MemberLocToStruct` in environment comparison. As an ancillary data structure, including it is redundant. We also can generate environments which differ in their `MemberLocToStruct` but are otherwise equivalent. Differential Revision: https://reviews.llvm.org/D126314
The scalar-default-character-expression that defines the interoperable name of a function or subroutine (or interface) must have its names resolved within the context of the subprogram, despite its appearance on a function-stmt or a subroutine-stmt. Failure to do so can lead to bogus errors or to incorrect results. The solution is to defer name resolution for function-stmt suffixes (but not entry-stmt suffixes) and for subroutine-stmt language binding specifications to EndSubprogram(). (Their resolution only need to be deferred to the end of the specification part, but it's cleanest to deal with it in EndSubprogram().) Differential Revision: https://reviews.llvm.org/D126153
The derived type information table construction code had a crash whose root cause was replacing an expression with one of its operands -- the deletion of the LHS of that assignment led to the RHS being invalidated before it could be read. Fix by cloning the RHS. Also update a TODO message to the new "_todo_en_US" message class and add a comment about how it should be resolved. Differential Revision: https://reviews.llvm.org/D126154
B/O/Z input overflow is already caught, and real input overflow is signalled as an IEEE arithmetic exception, but regular decimal integer overflow was silent. Differential Revision: https://reviews.llvm.org/D126155
This commit resolves a Linux kernel build failure that was revealed by c35ca3a. The patch introduces two new intrinsics, which ultimately changes the intrinsic numbering of other PPC intrinsics. This causes an issue introduced by ff40fb0, as the patch checks for intrinsics with particular values, but the addition of the fnabs/fnabss intrinsics updates the original sqrt/sdiv intrinsic values.
Since the FIR operations are mostly structured, it is only the functions that could contain multiple blocks inside an operation. This changes with OpenMP since OpenMP regions can contain multiple blocks. For unstructured code, the blocks are created in advance and belong to the top-level function. This caused code in OpenMP region to be placed under the function level. In this fix, if the OpenMP region is unstructured then new blocks are created inside it. Note1: This is part of upstreaming from the fir-dev branch of https://github.com/flang-compiler/f18-llvm-project. The code in this patch is a subset of the changes in flang-compiler#1178. Reviewed By: vdonaldson Differential Revision: https://reviews.llvm.org/D126293 Co-authored-by: Val Donaldson <vdonaldson@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: Valentin Clement <clementval@gmail.com>
Fixes: #55165 Differential Revision: https://reviews.llvm.org/D126168
This patch teaches the VSETVLI insertion pass to perform a very limited form of partial redundancy elimination. The motivating example comes from the fixed length vectorization of a simple loop such as:
for (unsigned i = 0; i < a_len; i++)
a[i] += b;
Without this change, the core vector loop and preheader is as follows:
.LBB0_3: # %vector.ph
andi a1, a6, -8
addi a4, a0, 16
mv a5, a1
.LBB0_4: # %vector.body
# =>This Inner Loop Header: Depth=1
addi a3, a4, -16
vsetivli zero, 4, e32, m1, ta, mu
vle32.v v8, (a3)
vle32.v v9, (a4)
vadd.vx v8, v8, a2
vadd.vx v9, v9, a2
vse32.v v8, (a3)
vse32.v v9, (a4)
addi a5, a5, -8
addi a4, a4, 32
bnez a5, .LBB0_4
The key thing to note here is that, the execution of the vsetivli only needs to happen once. Since there's no tail folding happening here, the value of the vector configuration registers are invariant through the loop.
After this patch, we hoist the configuration into the preheader and perform it once.
.LBB0_3: # %vector.ph
andi a1, a6, -8
vsetivli zero, 4, e32, m1, ta, mu
addi a4, a0, 16
mv a5, a1
.LBB0_4: # %vector.body
# =>This Inner Loop Header: Depth=1
addi a3, a4, -16
vle32.v v8, (a3)
vle32.v v9, (a4)
vadd.vx v8, v8, a2
vadd.vx v9, v9, a2
vse32.v v8, (a3)
vse32.v v9, (a4)
addi a5, a5, -8
addi a4, a4, 32
bnez a5, .LBB0_4
Differential Revision: https://reviews.llvm.org/D124869
Instead of matching opcodes to know the format to emit, use an enum value that we can get from the RISCVMatInt::Inst class. Change the consumers to use fully covered switches so that we get a compiler warning if a new kind is added. With the opcode checks it was easier to forget to update one of the 3 consumers. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D126317
Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D126318
When the AVL value does not fit in 5 bits, the register in which this value is stored may be dead when we want to forward it. This patch ensure the kill flags on the register are cleared before forwarding. Patch by: loralb Differential Revision: https://reviews.llvm.org/D125971
This creates an entry with address=nullptr and flag=0x80. When an 'omp_all_memory' entry is specified any other 'out' or 'inout' entries are not needed and are not passed to the runtime. Differential Revision: https://reviews.llvm.org/D126321
Simple implementations of the functions pthread_mutex_init, pthread_mutex_destroy, pthread_mutex_lock and pthread_mutex_unlock have have also been added. Future patches will extend these functions to add features required by the POSIX specification. Reviewed By: lntue Differential Revision: https://reviews.llvm.org/D126235
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D123631
Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D126335
…s are supported. Fixes: #55410
… to exit with an error code if any library file was not found. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D126336
5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the call to `getImmediateExpansionRange().getBegin()` with `getImmediateMacroCallerLoc()`, which has similar but subtly different behaviour. The consequence is that NOLINTs cannot suppress diagnostics when they are attached to a token that came from a macro **argument**, rather than elsewhere in the macro expansion. Revert to pre-patch behaviour and add test cases to cover this issue. Differential Revision: https://reviews.llvm.org/D126138
The LLDB website recommends using the CMake caches to build on macOS. Although modules result in a faster build, this configuration tends to break occasionally because it's specific to our platform. I don't expect newcomers to be able to deal with those kind of breakages so don't enable them by default.
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.