- Jul 30, 2020
-
-
Sanjay Patel authored
-
David Green authored
This removes some unneeded block masks when we don't have any reductions. It should not have any effect on codegen as the values created are dead anyway. Differential Revision: https://reviews.llvm.org/D81415
-
Louis Dionne authored
-
Stephan Herhut authored
Now that we can have a memref of index type, we no longer need to materialize shapes in i64 and then index_cast. Differential Revision: https://reviews.llvm.org/D84938
-
Christian Sigg authored
[MLIR] Don't pass separate LowerToLLVMOptions when we already pass a LLVMTypeConverter which contains those options already. This also prevents passing inconsistent options. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D84915
-
Abhishek Varma authored
-- Introduces a pass that normalizes the affine layout maps to the identity layout map both within and across functions by rewriting function arguments and call operands where necessary. -- Memref normalization is now implemented entirely in the module pass '-normalize-memrefs' and the limited intra-procedural version has been removed from '-simplify-affine-structures'. -- Run using -normalize-memrefs. -- Return ops are not handled and would be handled in the subsequent revisions. Signed-off-by:
Abhishek Varma <abhishek.varma@polymagelabs.com> Differential Revision: https://reviews.llvm.org/D84490
-
Stephan Herhut authored
Differential Revision: https://reviews.llvm.org/D84934
-
Jean Perier authored
The intrinsic lowering facility is based on the generic intrinsic names to avoid duplicating implementations. Specific intrinsics call are re-written to call to the generic versions by the front-end but this cannot be done when specific intrinsics are passed as arguments (the rewrite would give illegal/ambiguous unparsed Fortran). Solve the issue by making the specific to generic name mapping accessible to lowering and can be later used to generate the unrestricted intrinsic functions. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D84842
-
Florian Hahn authored
This reverts commit e77624a3. Looks like some clang tests manually invoke -ipconstprop via opt.....
-
Frederik Gossen authored
When lowering to the standard dialect, we currently support only the extent tensor variant of the shape.rank operation. This change lets the conversion pattern fail in a well-defined manner. Differential Revision: https://reviews.llvm.org/D84852
-
Florian Hahn authored
As far as I know, ipconstprop has not been used in years and ipsccp has been used instead. This has the potential for confusion and sometimes leads people to spend time finding & reporting bugs as well as updating it to work with the latest API changes. This patch moves the tests over to SCCP. There's one functional difference I am aware of: ipconstprop propagates for each call-site individually, so for functions that are called with different constant arguments it can sometimes produce better results than ipsccp (at much higher compile-time cost).But IPSCCP can be thought to do so as well for internal functions and as mentioned earlier, the pass seems unused in practice (and there are no plans on working towards enabling it anytime). Also discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2020-July/143773.html Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D84447
-
Simon Pilgrim authored
Replace TargetLibraryInfo.h include with forward declaration and fix implicit dependencies. Reduce SmallSet.h include to SmallVector.h include.
-
Simon Pilgrim authored
As long as we can extract the lowest 128-bit subvector from the pre-truncated source vector, then we don't care what size it is. The next stage will be to support non-zero extraction indices, as long as its still coming from the lowest 128-bit subvector.
-
Kirill Bobyrev authored
This is the last missing bit in the core remote index implementation. The only remaining bits are some API refactorings (replacing Optional with Expected and being better at reporting errors). Reviewed By: kadircet Differential Revision: https://reviews.llvm.org/D84894
-
Florian Hahn authored
-
Raphael Isemann authored
Let's just return a std::string to make this safe. formatv seemed overkill for formatting the return values as they all just append an integer value to a constant string. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D84505
-
Esme-Yi authored
-
Aleksandr Platonov authored
Without this patch the word occurrence search always returns the first token of the file. Despite of that, `findNeardyIdentifier()` returns the correct result (but inefficently) until there are several matched tokens with the same value `floor(log2(<token line> - <word line>))` (e.g. several matched tokens on the same line). Reviewed By: kadircet Differential Revision: https://reviews.llvm.org/D84912
-
Xing GUO authored
This patch makes the 'Length' field of the address range table optional. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D84911
-
Xing GUO authored
This patch makes the 'AddressSize' and 'SegmentSelectorSize' fields of address range table optional. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D84907
-
Sam Tebbs authored
This patch adds a DAG combine fold for a sext(masked_load) into a sign extended masked load. Differential Revision: https://reviews.llvm.org/D84332
-
Nathan James authored
Ordering of options isn't important so an `llvm::StringMap` is a much better container for this purpose. Reviewed By: gribozavr2 Differential Revision: https://reviews.llvm.org/D84868
-
David Truby authored
Summary: Currently the binaries are output directly into the bin subdirectory of the build directory. This doesn't work correctly with multi-config generators which should output the binaries into <CONFIG_NAME>/bin instead. Reviewers: sscalpone, richard.barton.arm Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D84022
-
Florian Hahn authored
Preparation for D84447.
-
Rainer Orth authored
As requested in the review, this patch removes the additional conditions in the `COMPILER_RT_HAS_VERSION_SCRIPT` tests. Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`. Differential Revision: https://reviews.llvm.org/D84559
-
George Mitenkov authored
This patch introduces new intrinsics in LLVM dialect: - `llvm.intr.floor` - `llvm.intr.maxnum` - `llvm.intr.minnum` - `llvm.intr.smax` - `llvm.intr.smin` These intrinsics correspond to SPIR-V ops from GLSL extended instruction set (`spv.GLSL.Floor`, `spv.GLSL.FMax`, `spv.GLSL.FMin`, `spv.GLSL.SMax` and `spv.GLSL.SMin` respectively). Also conversion patterns for them were added. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D84661
-
Kang Zhang authored
Summary: In the phi-node-elimination pass, we set the killed flag incorrectly. When we eliminate the PHI node, we replace the PHI with a copy for the incoming value. Before this patch, we will set incoming value as killed(PHICopy). And we will remove the killed flag from last using incoming value(OldKill). This is correct, only if the new PHICopy is after the OldKill. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D80886
-
George Mitenkov authored
This is a second patch on conversion of GLSL ops to LLVM dialect. It introduces patterns to convert `spv.InverseSqrt` and `spv.Tanh`. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D84633
-
Balázs Kéri authored
The uniqueing decl in PathDiagnostic is the declaration with the uniqueing loc, as stated by documentation comments. It is enough to include the uniqueing loc in the profile. It is possible to have objects with different uniqueing decl but same location, at least with templates. These belong to the same class and should have same profile. Reviewed By: vsavchenko, NoQ Differential Revision: https://reviews.llvm.org/D84843
-
David Sherwood authored
When building code at -O0 We weren't falling back to DAG ISel correctly when encountering alloca instructions with scalable vector types. This is because the alloca has no operands that are scalable. I've fixed this by adding a check in AArch64ISelLowering::fallBackToDAGISel for alloca instructions with scalable types. Differential Revision: https://reviews.llvm.org/D84746
-
Haojian Wu authored
`TemplateTypeParmDecl::hasTypeConstraint` is not a safe guard for checking `TemplateTypeParmDecl::getTypeConstraint()` result is null. in somecases (e.g. implicit deduction guide templates synthesized from the constructor, immediately-declared constraint is not formed because of an error), hasTypeConstraint returns false, and getTypeConstraint returns a nullptr. Fix https://bugs.llvm.org/show_bug.cgi?id=46790 Differential Revision: https://reviews.llvm.org/D84455
-
George Mitenkov authored
This is the first patch that adds support for GLSL extended instruction set ops. These are direct conversions, apart from `spv.Tan` that is lowered to `sin() / cos()`. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D84627
-
Haojian Wu authored
The assertion is not true anymore after D82739, this patch just removes it, and rename related functions. And also fixes a missing cases. Differential Revision: https://reviews.llvm.org/D84837
-
Craig Topper authored
Continue the change made to ParseATTOperand to take the vector by reference. Let ParseMemOperand add its memory operand to the vector and just return true/false to indicate error.
-
Craig Topper authored
Pointers and SMLocs are cheap to copy. Even though the function modifies some of these the caller doesn't use them after the call.
-
Serge Pavlov authored
This change define RAII class `FileLocker` and methods `lock` and `tryLockFor` of the class `raw_fd_stream` to facilitate using file locks. Differential Revision: https://reviews.llvm.org/D79066
-
Max Kazantsev authored
-
Balázs Kéri authored
Use of BuiltinBug is replaced by BugType. Class BuiltinBug seems to have no benefits and is confusing. Reviewed By: Szelethus, martong, NoQ, vsavchenko Differential Revision: https://reviews.llvm.org/D84494
-
Tony authored
-
Tony authored
- Clarify that these are extensions to DWARF 5 and not as yet a proposal. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D70523
-