- Jun 07, 2022
-
-
Philip Reames authored
-
Vasileios Porpodas authored
Differential Revision: https://reviews.llvm.org/D126938
-
Craig Topper authored
Move the code that was added for D126896 after the normal recursive calls to computeKnownBits. This allows us to calculate trailing zeros. Previously we would break out of the switch before the recursive calls.
-
Louis Dionne authored
-
Louis Dionne authored
Currently, unary expressions involving valarray will create a temporary. This leads to dangling references in expressions like `-a * b`, because `-a` is a temporary and the resulting expression will refer to it. This patch fixes the problem by creating a lazy expression to perform the unary operation instead of eagerly creating a temporary valarray. This is permitted by the Standard, which does not specify the exact type of most expressions involving valarrays. This is technically an ABI break, however I believe the actual potential for breakage is very low. rdar://90152242 Differential Revision: https://reviews.llvm.org/D125019
-
Chris Bieneman authored
Using the pointer type analysis we can re-constitute typed pointers and populate the correct types in the bitcasts throughout the IR. This doesn't yet handle all cases, but this should be illustrative as to the dirction and feasability of the solution. Reviewed By: pete Differential Revision: https://reviews.llvm.org/D122270
-
Chris Bieneman authored
This test was failing on 32-bit arm builders due to an interger overflow. This changes the math to avoid overflow and should resolve the test failure.
-
- Jun 06, 2022
-
-
Ivan Kosarev authored
Resolves part of https://github.com/llvm/llvm-project/issues/38652 Reviewed By: dp Differential Revision: https://reviews.llvm.org/D126791
-
Sanjay Patel authored
-
Ivan Kosarev authored
Resolves part of https://github.com/llvm/llvm-project/issues/38652 Reviewed By: dp Differential Revision: https://reviews.llvm.org/D126766
-
Dmitry Preobrazhensky authored
Summary of changes: - Updated MUBUF lds syntax (see https://reviews.llvm.org/D124485). - Enabled literals with src0 for v_madak*, v_madmk* (see https://reviews.llvm.org/D111067). - Minor bug fixing.
-
Alex Brachet authored
-
Joe Nash authored
Includes dpp instructions and vop1/vop2 promoted to vop3 Patch 17/N for upstreaming of AMDGPU gfx11 architecture Depends on D126483 Reviewed By: rampitec, #amdgpu Differential Revision: https://reviews.llvm.org/D126917
-
Joe Nash authored
gfx11 adds the ability to use dpp modifiers on vop3 instructions. This patch adds machine code layer support for that. The MCCodeEmitter is changed to use APInt instead of uint64_t to support these wider instructions. Patch 16/N for upstreaming of AMDGPU gfx11 architecture Depends on D126475 Reviewed By: rampitec, #amdgpu Differential Revision: https://reviews.llvm.org/D126483
-
Louis Dionne authored
Instead of providing two different constructors for iterators that support the debug mode, provide a single constructor but leave the container parameter unused when the debug mode is not enabled. This allows simplifying all the call sites to unconditionally pass the container, which removes a bunch of duplication in the container's implementation. Note that this patch does add some complexity to std::span, however that is only because std::span has the ability to use raw pointers as iterators instead of __wrap_iter. In retrospect, I believe it was a mistake to provide that capability, and so it will be removed in a future patch, along with the complexity added by this patch. Differential Revision: https://reviews.llvm.org/D126993
-
Kevin P. Neal authored
In D115737 I found that I needed to teach Instruction::isSafeToRemove() about strictfp/constrained intrinsics. It was pointed out that this is probably the wrong function to use isInstructionTriviallyDead(). It doesn't make sense to have a "second, worse implementation". I also believe that the Instruction class is the wrong place for this functionality. The information about whether or not an instruction can be removed is in the transform passes and should stay there. Differential Revision: https://reviews.llvm.org/D118387
-
Andrzej Warzynski authored
This is a follow-up of https://reviews.llvm.org/D125832 (see also https://reviews.llvm.org/D125788 for more context). It simply removes any remaining references to the `flang` bash script. Note that that `flang-to-external-fc` remains intact. This felt worthwhile mentioning in the release notes, which have not been updated since LLVM 12 (we are approaching LLVM 15 now). I took the liberty of removing all of the out-dated content and added a note about the renaming. Differential Revision: https://reviews.llvm.org/D127094
-
Dmitry Preobrazhensky authored
Summary of changes: - Updated MUBUF lds syntax (see https://reviews.llvm.org/D124485). - Enabled literals with src0 of v_madak_f32, v_madmk_f32 (see https://reviews.llvm.org/D111067). - Corrected LGKM_CNT description. - Minor bug fixing.
-
Aaron Ballman authored
This should address bot failures like: https://lab.llvm.org/buildbot/#/builders/77/builds/18317
-
LLVM GN Syncbot authored
-
Nikolas Klauser authored
Reviewed By: Mordante, var-const, ldionne, #libc Spies: sstefan1, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D121964
-
Aaron Ballman authored
Currently, Clang accepts this code in C mode (where the tag is required to be used) but rejects it in C++ mode thinking that the association is defining a new type. void foo(void) { struct S { int a; }; _Generic(something, struct S : 1); } Clang thinks this in C++ because it sees struct S : when parsing the class specifier and decides that must be a type definition (because the colon signifies the presence of a base class type). This patch adds a new declarator context to represent a _Generic association so that we can distinguish these situations properly. Fixes #55562 Differential Revision: https://reviews.llvm.org/D126969 -
David Green authored
This adds a fold of add(x, shuffle(x, <1,0,3,2,5,4,...>), into shuffle(addp(x), <0,0,1,1,2,2,..>. The ADDP instruction takes two vectors and returns one, adding adjacent pairs. So we match x in a custom combine as it is lowered from a v8i32. The original code would be 2 rev64 and 2 add, with the new code being a single addp with a zip1;zip2 shuffle, producing smaller code. Differential Revision: https://reviews.llvm.org/D126686
-
Simon Pilgrim authored
-
Nico Weber authored
-
Nico Weber authored
-
Nimish Mishra authored
OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives. This patch adds parser support for the same. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D124156
-
Kai Luo authored
Support allocation of huge stack frame(>2g) on PPC64. For ELFv2 ABI on Linux, quoted from the spec 2.2.3.1 General Stack Frame Requirements > There is no maximum stack frame size defined. On AIX, XL allows such huge frame. Reviewed By: #powerpc, nemanjai Differential Revision: https://reviews.llvm.org/D107886
-
Florian Hahn authored
Try to simplify BranchOnCount to `BranchOnCond true` if TC <= UF * VF. This is an alternative to D121899 which simplifies the VPlan directly instead of doing so late in code-gen. The potential benefit of doing this in VPlan is that this may help cost-modeling in the future. The reason this is done in prepareToExecute at the moment is that a single plan may be used for multiple VFs/UFs. There are further simplifications that can be applied as follow ups: 1. Replace inductions with constants 2. Replace vector region with regular block. Fixes #55354. Depends on D126679. Reviewed By: Ayal Differential Revision: https://reviews.llvm.org/D126680
-
David Spickett authored
This reverts commit d4220af5. Linaro bots are back online.
-
Shao-Ce SUN authored
Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D125083
-
yanming authored
-
Kazu Hirata authored
-
yanming authored
The default RegisterClass is not enough to model RISCV Register. We define risc-v's own register class to model FP Register. This helps to better estimate the register pressure in the loop-vectorize. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D126854
-
Qingyuan Zheng authored
Fixes https://github.com/clangd/clangd/issues/1132 where clangd's semantic highlighting is missing for symbols of a template specialization definition. It turns out the visitor didn't traverse the base classes of Class/Var##TemplateSpecializationDecl, i.e. CXXRecordDecl/VarDecl. This patch adds them back as what is done in DEF_TRAVERSE_TMPL_PART_SPEC_DECL. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D126757
-
Kazu Hirata authored
- truncateQuotedNameFront: The last use was removed on Jul 10, 2017 in commit a9d944fd. - truncateQuotedNameBack: The last use was removed on Mar 26, 2018 in commit 7b84b678. - truncateStringMiddle: The last use was removed on Mar 26, 2018 in commit 7b84b678. - truncateStringBack: The last use is in truncateQuotedNameBack being removed above. - truncateStringFront: The last use is in truncateQuotedNameFront being removed above.
-
Chuanqi Xu authored
promise_type Address the post-commit comment in https://reviews.llvm.org/D125517#inline-1217244
-
Chris Bieneman authored
This patch adds an llvm-driver multicall tool that can combine multiple LLVM-based tools. The build infrastructure is enabled for a tool by adding the GENERATE_DRIVER option to the add_llvm_executable CMake call, and changing the tool's main function to a canonicalized tool_name_main format (i.e. llvm_ar_main, clang_main, etc...). As currently implemented llvm-driver contains dsymutil, llvm-ar, llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the build). llvm-driver can be enabled from builds by setting LLVM_TOOL_LLVM_DRIVER_BUILD=On. There are several limitations in the current implementation, which can be addressed in subsequent patches: (1) the multicall binary cannot currently properly handle multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver will not properly result in llvm-ar's main being called. (2) the multicall binary cannot be comprised of tools containing conflicting cl::opt options as the global cl::opt option list cannot contain duplicates. These limitations can be addressed in subsequent patches. Differential revision: https://reviews.llvm.org/D109977
-
Brad Smith authored
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D123845
-
Kazu Hirata authored
The last use was removed on Mar 7, 2022 in commit 294eca35.
-