- Feb 04, 2021
-
-
Andrzej Warzynski authored
This new action encapsulates all actions that require the prescanner to be run before proceeding with other processing. By adding this new action, we are better equipped to control which actions _do_ run the prescanner and which _do not_. The following actions that require the prescanner are refactored to inherit from `PrescanAction`: * `PrintPreprocessedAction` * `ParseSyntaxOnlyAction` . New virtual method is introduced to facilitate all this: * `BeginSourceFileAction` Like in Clang, this method is run inside `BeginSourceFile`. In other words, it is invoked before `ExecuteAction` for the corresponding frontend action is run. This method allows us to: * carry out any processing that is always required by the action (e.g. run the prescanner) * fine tune the settings/options on a file-by-file basis (e.g. to decide between fixed-form and free-form based on file extension) This patch implements non-functional-changes. Reviewed By: FarisRehman Differential Revision: https://reviews.llvm.org/D95464 -
Sander de Smalen authored
This patch migrates cost values and arithmetic to work on InstructionCost. When the interfaces to TargetTransformInfo are changed, any InstructionCost state will propagate naturally. See this patch for the introduction of the type: https://reviews.llvm.org/D91174 See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html Reviewed By: david-arm, fhahn Differential Revision: https://reviews.llvm.org/D95817
-
Anastasia Stulova authored
Tags: #clang Differential Revision: https://reviews.llvm.org/D95886
-
Florian Hahn authored
This patch extends the condition collection logic to allow adding conditions from pre-headers to loop headers, by allowing cases where the target block dominates some of its predecessors.
-
Anastasia Stulova authored
When deducing a reference type for forwarding references prevent adding default address space of a template argument if it is given. This got reported in PR48896 because in OpenCL all parameters are in private address space and therefore when we initialize a forwarding reference with a parameter we should just inherit the address space from it i.e. keep __private instead of __generic. Tags: #clang Differential Revision: https://reviews.llvm.org/D95624
-
Alexander Belyaev authored
Differential Revision: https://reviews.llvm.org/D96024
-
Konstantin Zhuravlyov authored
If amdgpu-unsafe-fp-atomics is specified, allow {flat|global}_atomic_add_f32 even if atomic modes don't match. Differential Revision: https://reviews.llvm.org/D95391 -
Dylan McKay authored
It was discussed a few years ago and agreed that it makes sense to remove this assertion as other targets do not perform similar register size checking in inline assembly constraint logic, so the check just adds a needless barrier on AVR. This patch removes the assertion and removes 'XFAIL' from two Generic CodeGen tests for AVR as a result.
-
Andrzej Warzynski authored
This makes sure that AddClang.cmake is installed alongside other Clang CMake modules. This mirrors LLVM and MLIR in this respect and is required when building the new Flang driver out of tree (as it depends on Clang and includes AddClang.cmake). Reviewed By: bogner Differential Revision: https://reviews.llvm.org/D94533
-
Faris Rehman authored
Add support for the following layout options: * -ffree-form * -ffixed-form - -ffixed-line-length=n (alias -ffixed-line-length-n) Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags. This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a754968, these flags are not currently forwarded to gfortran anyway. The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran. This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns. Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files. Summary of changes: - Remove -fno-fixed-form and -fno-free-form from Options.td - Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td - Create AddFortranDialectOptions method in Flang.cpp - Create FortranForm enum in FrontendOptions.h - Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions - Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing. Differential Revision: https://reviews.llvm.org/D95460
-
Simon Pilgrim authored
We now handle implicit zero-extension shuffle mask cases.
-
Nico Weber authored
This reverts commit a2fdf9d4. Slightly speculative, seeing several cuda tests fail on this Windows bot: http://45.33.8.238/win/32620/step_7.txt
-
Nico Weber authored
-
Sander de Smalen authored
These class methods simply return a new UnivariateLinearPolyBase (e.g. ElementCount), and do not modify the object in any way or form, so qualify for being 'const'.
-
Nicolas Vasilache authored
This op is subsumed by rank-reducing SubViewOp and has become useless. Differential revision: https://reviews.llvm.org/D95317
-
Jeremy Morse authored
This modified patch avoids redirecting the unit in which a subprogram is created if type units are enabled -- DIEs were getting children allocated from different units memory pools. Original commit message: [DWARF] Create subprogram's DIE in DISubprogram's unit This is a fix for PR48790. Over in D70350, subprogram DIEs were permitted to be shared between CUs. However, the creation of a subprogram DIE can be triggered early, from other CUs. The subprogram definition is then created in one CU, and when the function is actually emitted children are attached to the subprogram that expect to be in another CU. This breaks internal CU references in the children. Fix this by redirecting the creation of subprogram DIEs in getOrCreateContextDIE to the CU specified by it's DISubprogram definition. This ensures that the subprogram DIE is always created in the correct CU. Differential Revision: https://reviews.llvm.org/D94976
-
David Green authored
This new f16 shuffle under Neon would hit an assert in GeneratePerfectShuffle as it would try to treat a f16 vector as an i8. Add f16 handling, treating them like an i16. Differential Revision: https://reviews.llvm.org/D95446
-
Alex Zinenko authored
Historically, the Vector to LLVM dialect conversion subsumed the Standard to LLVM dialect conversion patterns. This was necessary because the conversion infrastructure did not have sufficient support for reconciling type conversions. This support is now available. Only keep the patterns related to the Vector dialect in the Vector to LLVM conversion and require type casts operations to be inserted if necessary. These casts will be removed by following conversions if possible. Update integration tests to also run the Standard to LLVM conversion. There is a significant amount of test churn, which is due to (a) unnecessarily strict tests in VectorToLLVM and (b) many patterns actually targeting Standard dialect ops instead of LLVM dialect ops leading to tests actually exercising a Vector->Standard->LLVM conversion. This churn is a good illustration of the reason to make the conversion partial: now the tests only check the code in the Vector to LLVM conversion and will not be randomly broken by changes in Standard to LLVM conversion. Arguably, it may be possible to extract Vector to Standard patterns into a separate pass, but given the ongoing splitting of the Standard dialect, such pass will be short-lived and will require further refactoring. Depends On D95626 Reviewed By: nicolasvasilache, aartbik Differential Revision: https://reviews.llvm.org/D95685
-
Pavel Labath authored
The new PM is more aggressive at inlining, which breaks assumptions in the test => slap some __attribute__((noinlines)) to prevent that.
-
Alex Zinenko authored
In dialect conversion infrastructure, source materialization applies as part of the finalization procedure to results of the newly produced operations that replace previously existing values with values having a different type. However, such operations may be created to replace operations created in other patterns. At this point, it is possible that the results of the _original_ operation are still in use and have mismatching types, but the results of the _intermediate_ operation that performed the type change are not in use leading to the absence of source materialization. For example, %0 = dialect.produce : !dialect.A dialect.use %0 : !dialect.A can be replaced with %0 = dialect.other : !dialect.A %1 = dialect.produce : !dialect.A // replaced, scheduled for removal dialect.use %1 : !dialect.A and then with %0 = dialect.final : !dialect.B %1 = dialect.other : !dialect.A // replaced, scheduled for removal %2 = dialect.produce : !dialect.A // replaced, scheduled for removal dialect.use %2 : !dialect.A in the same rewriting, but only the %1->%0 replacement is currently considered. Change the logic in dialect conversion to look up all values that were replaced by the given value and performing source materialization if any of those values is still in use with mismatching types. This is performed by computing the inverse value replacement mapping. This arguably expensive manipulation is performed only if there were some type-changing replacements. An alternative could be to consider all replaced operations and not only those that resulted in type changes, but it would harm pattern-level composability: the pattern that performed the non-type-changing replacement would have to be made aware of the type converter in order to call the materialization hook. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D95626
-
Hans Wennborg authored
As discussed in https://lists.llvm.org/pipermail/cfe-dev/2021-January/067524.html It doesn't appear to be used, isn't really maintained, and adds some complexity to the code. Let's remove it. Differential revision: https://reviews.llvm.org/D95876
-
Jan Svoboda authored
This patch implements generation of remaining header search arguments. It's done manually in C++ as opposed to TableGen, because we need the flexibility and don't anticipate reuse. This patch also tests the generation of header search options via a round-trip. This way, the code gets exercised whenever Clang is built and tested in asserts mode. All `check-clang` tests pass. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D94472
-
Joachim Meyer authored
As noted in https://reviews.llvm.org/D93459, the formatting of multi-line descriptions of clEnumValN and the likes is unfavorable. Thus this patch adds support for correctly indenting these. Reviewed By: serge-sans-paille Differential Revision: https://reviews.llvm.org/D93494
-
Sebastian Neubauer authored
When SGPRs are spilled to VGPRs, they can overwrite any lane. We need to preserve the value of inactive lanes in function calls, so we save the register even if it is marked as caller saved. Also, teach buildPrologSpill to work when no registers are free like in CodeGen/AMDGPU/pei-scavenge-vgpr-spill.mir and update the comment on findScratchNonCalleeSaveRegister as it is not used anymore to realign the stack pointer since D95865. Differential Revision: https://reviews.llvm.org/D95946
-
Kirill Bobyrev authored
This patch allows detecting conflicts with variables defined in the current CompoundStmt or If/While/For variable init statements. Reviewed By: hokein Differential Revision: https://reviews.llvm.org/D95925
-
Haojian Wu authored
Differential Revision: https://reviews.llvm.org/D95782
-
Nicolas Vasilache authored
This revision defines a Linalg contraction in general terms: 1. Has 2 input and 1 output shapes. 2. Has at least one reduction dimension. 3. Has only projected permutation indexing maps. 4. its body computes `u5(u1(c) + u2(u3(a) * u4(b)))` on some field (AddOpType, MulOpType), where u1, u2, u3, u4 and u5 represent scalar unary operations that may change the type (e.g. for mixed-precision). As a consequence, when vectorization of such an op occurs, the only special behavior is that the (unique) MulOpType is vectorized into a `vector.contract`. All other ops are handled in a generic fashion. In the future, we may wish to allow more input arguments and elementwise and constant operations that do not involve the reduction dimension(s). A test is added to demonstrate the proper vectorization of matmul_i8_i8_i32. Differential revision: https://reviews.llvm.org/D95939 -
Richard Smith authored
-
Richard Smith authored
doubly-nested implicit CXXConstructExprs. Ensure that we transform the parameter initializer using TransformInitializer rather than TransformExpr so that we properly strip down and rebuild the initialization, including any necessary CXXBindTemporaryExprs. Otherwise we can end up forgetting to destroy temporary objects used to construct a constructor parameter.
-
Nicolas Vasilache authored
This separation improves the layering and paves the way for more interfaces coming up in the future. Differential revision: https://reviews.llvm.org/D95941
-
Michael Liao authored
- On Windows, extended lambda has extra issues due to the numbering schemes are different between the host compilation (Microsoft C++ ABI) and the device compilation (Itanium C++ ABI. Additional device side lambda number is required per lambda for the host compilation to correctly mangle the device-side lambda name. - A hybrid numbering context `MSHIPNumberingContext` is introduced to number a lambda for both host- and device-compilations. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D69322
-
wlei authored
This change compresses the context string by removing cycles due to recursive function for CS profile generation. Removing recursion cycles is a way to normalize the calling context which will be better for the sample aggregation and also make the context promoting deterministic. Specifically for implementation, we recognize adjacent repeated frames as cycles and deduplicated them through multiple round of iteration. For example: Considering a input context string stack: [“a”, “a”, “b”, “c”, “a”, “b”, “c”, “b”, “c”, “d”] For first iteration,, it removed all adjacent repeated frames of size 1: [“a”, “b”, “c”, “a”, “b”, “c”, “b”, “c”, “d”] For second iteration, it removed all adjacent repeated frames of size 2: [“a”, “b”, “c”, “a”, “b”, “c”, “d”] So in the end, we get compressed output: [“a”, “b”, “c”, “d”] Compression will be called in two place: one for sample's context key right after unwinding, one is for the eventual context string id in the ProfileGenerator. Added a switch `compress-recursion` to control the size of duplicated frames, default -1 means no size limit. Added unit tests and regression test for this. Differential Revision: https://reviews.llvm.org/D93556
-
Ben Barham authored
A module in the cache with an error should just be a cache miss. If allowing errors (with -fallow-pcm-with-compiler-errors), a rebuild is needed so that the appropriate diagnostics are output and in case search paths have changed. If not allowing errors, the module was built *allowing* errors and thus should be rebuilt regardless. Reviewed By: akyrtzi Differential Revision: https://reviews.llvm.org/D95989
-
Petr Hosek authored
-
Dave Lee authored
Follow up to D95813, this converts multiline assertTrue to assertEqual. Differential Revision: https://reviews.llvm.org/D95899
-
Chuanqi Xu authored
The functionallity in the TODO was added before: https://reviews.llvm.org/rGb3a722e66b75328ab5e2eb5c8572022cb083855b
-
Kazu Hirata authored
-
Kazu Hirata authored
-