- Mar 16, 2022
-
-
Shengchen Kan authored
This is preparation for D121768. The member's name should align w/ the interface for trival target feature.
-
MaheshRavishankar authored
https://reviews.llvm.org/D121369 fixed an issue with canonicalizing a linalg op producer with a cast op consumer. Adding a test to verify that change. Reviewed By: hanchung Differential Revision: https://reviews.llvm.org/D121648
-
River Riddle authored
A fake unreachable was created and removed, but never erased.
-
Alex Brachet authored
-
Alex Brachet authored
We were in between two styles when this file was initially checked in.
-
Manoj Gupta authored
glibc >= 2.33 uses shared functions for stat family functions. D111984 added support for non-64 bit variants but they do not appear to be enough as we have been noticing msan errors on 64-bit stat variants on Chrome OS. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D121652
-
Sterling Augustine authored
Differential Revision: https://reviews.llvm.org/D121764
-
Fangrui Song authored
https://discourse.llvm.org/t/parallel-input-file-parsing/60164 initializeSymbols currently sets Defined::section and handles non-prevailing COMDAT groups. Move the code to the parallel postParse to reduce work from the single-threading code path and make parallel section initialization infeasible. Postpone reporting duplicate symbol errors so that the messages have the section information. (`Defined::section` is assigned in postParse and another thread may not have the information). * duplicated-synthetic-sym.s: BinaryFile duplicate definition (very rare) now has no section information * comdat-binding: `%t/w.o %t/g.o` leads to an undesired undefined symbol. This is not ideal but we report a diagnostic to inform that this is unsupported. (See release note) * comdat-discarded-lazy.s: %tdef.o is unextracted. The new behavior (discarded section error) makes more sense * i386-comdat.s: switched to a better approach working around .gnu.linkonce.t.__x86.get_pc_thunk.bx in glibc<2.32 for x86-32. Drop the ancient no-longer-relevant workaround for __i686.get_pc_thunk.bx Depends on D120640 Differential Revision: https://reviews.llvm.org/D120626
-
Haocong.Lu authored
Select SRLI+SLLI for and i64 %x, imm if the imm is a leading ones mask. It's useful in RV64 when the mask exceeds simm32 (cannot be generated by LUI). Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D121598
-
Sam McCall authored
Seems to have been added accidentally in 58db03a1 and then copied into clangd by me (but not actually needed).
-
Fangrui Song authored
This reverts commit c30e6447. It exposed brittle support for __x86.get_pc_thunk.bx. Need to think a bit how to support __x86.get_pc_thunk.bx.
-
Fangrui Song authored
Make it behave like the glibc<2.32 .gnu.linkonce usage that we want to work around.
-
Shafik Yaghmour authored
Removing comment out code, looks like debugging code left over from a while ago.
-
Vitaly Buka authored
-
Sam Clegg authored
In particular we use these in two places: 1. When building PIC code we no longer need to combine output segments into a single segment that can be initialized at `__memory_base`. Instead each segment can encode its offset from `__memory_base` in its initializer. e.g. ``` (i32.add (global.get __memory_base) (i32.const offset) ``` 2. When building PIC code we no longer need to relocation internalized global addresses. We can just initialize them with their correct offsets. Differential Revision: https://reviews.llvm.org/D121420
-
Zequan Wu authored
-
Nico Weber authored
-
Aart Bik authored
Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D121743
-
River Riddle authored
PDLInterp is effectively an internal dialect, so there isn't a need to stage the switch.
-
River Riddle authored
-
Jez Ng authored
Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the `interposable` used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506 -
Fangrui Song authored
-
Tobias Nießen authored
This merely adds a missing "an" in the introductory sentence. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D121760
-
Sam McCall authored
This reverts commit 049f4e4e. The problem was a stray dependency in CLANG_TEST_DEPS which caused cmake to fail if clang-pseudo wasn't built. This is now removed.
-
Sam McCall authored
This reverts commit b97856c4. Breaks a bunch of bots: https://lab.llvm.org/buildbot/#/builders/193/builds/8513
-
Michael Jones authored
previously the support_standalone_cpp target contained all of the files in the __support/cpp folder. This change splits these out so that only what is needed is included. In addition, this change adds the new support files that previously didn't have targets. Reviewed By: lntue, gchatelet Differential Revision: https://reviews.llvm.org/D121314
-
Philip Reames authored
This initial patch adds code to preserve MemorySSA through a run of SLP vectorizer. The eventual plan is to use MemorySSA to accelerate SLP's memory dependence checking, but we're a ways from that. In particular, this patch is correct, but really slow. It's being landed so that we can work incrementally in tree, not because it's expected to be useful to anyone just yet. The broader effort is being tracked in https://github.com/llvm/llvm-project/issues/54256. Its worth noting expicitly that this may not work out, and if not, we will be reverting all of the MSSA support in SLP at some point in the next few weeks. Differential Revision: https://reviews.llvm.org/D117926
-
Sam McCall authored
This should make clearer that: - it's not part of clang proper - there's no expectation to update it along with clang (beyond green tests) - clang should not depend on it This is intended to be expose a library, so unlike other tools has a split between include/ and lib/. The main renames are: clang/lib/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/lib/* clang/include/clang/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/include/clang-pseudo/* clang/tools/clang/pseudo/* => clang-tools-extra/pseudo/tool/* clang/test/Syntax/* => clang-tools-extra/pseudo/test/* clang/unittests/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/unittests/* #include "clang/Tooling/Syntax/Pseudo/*" => #include "clang-pseudo/*" namespace clang::syntax::pseudo => namespace clang::pseudo check-clang => check-clang-pseudo clangToolingSyntaxPseudo => clangPseudo The clang-pseudo and ClangPseudoTests binaries are not renamed. See discussion around: https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217/50 Differential Revision: https://reviews.llvm.org/D121233
-
Nico Weber authored
-
Bixia Zheng authored
PyTACO DSL doesn't support the use of index values as in A[i] = B[i]+ i. We extend the DSL to support such a use in MLIR-PyTACO. Remove an obsolete unit test. Add unit tests and PyTACO tests. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D121716
-
Sam Clegg authored
This is a new mode for handling unresolved symbols that allows all symbols to be imported in the same that they would be in the case of `-fpie` or `-shared`, but generting an otherwise fixed/non-relocatable binary. Code linked in this way should still be compiled with `-fPIC` so that data symbols can be resolved via imports. This essentially allows the building of static binaries that have dynamic imports. See: https://github.com/emscripten-core/emscripten/issues/12682 As with other uses of the experimental dynamic linking ABI, this behaviour will produce a warning unless run with `--experimental-pic`. Differential Revision: https://reviews.llvm.org/D91577
-
Valentin Clement authored
This is a fix for failing buildbot https://lab.llvm.org/buildbot/#/builders/172/builds/9652
-
River Riddle authored
FuncOp is being moved out of the builtin dialect, and defining a custom toy operation showcases various aspects of defining function-like operation (e.g. inlining, passes, etc.). Differential Revision: https://reviews.llvm.org/D121264
-
River Riddle authored
Defining our own function operation allows for the PDL interpreter to be more self contained, and also removes any dependency on FuncOp; which is moving out of the Builtin dialect. Differential Revision: https://reviews.llvm.org/D121253
-
Siva Chandra Reddy authored
-
Ian Bearman authored
During MLIR translation to LLVMIR if an inlineable call has an UnkownLoc we get this error message: ``` inlinable function call in a function with debug info must have a !dbg location call void @callee() ``` There is code that checks for this case and strips debug information to avoid this situation. I'm expanding this code to handle the case where an debug location points at a UnknownLoc. For example, a NamedLoc whose child location is an UnknownLoc. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D121633
-
Fangrui Song authored
-
Jonas Devlieghere authored
The log channel was changed from Types to Commands in a007a6d8: - Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS | LIBLLDB_LOG_TYPES)); + Log *log = GetLog(LLDBLog::Process | LLDBLog::Commands);
-
Valentin Clement authored
-
Valentin Clement authored
Thsi patch add the infrastructure to lower the random related intrinsics: - `random_init` - `random_number` - `random_seed` This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: PeteSteinfeld, schweitz Differential Revision: https://reviews.llvm.org/D121704 Co-authored-by:
V Donaldson <vdonaldson@nvidia.com> Co-authored-by:
Jean Perier <jperier@nvidia.com>
-