- Oct 15, 2018
-
-
Haojian Wu authored
Summary: This would allow easily injecting our internal customization. Also updates the stale "symbol-collection-file" flag. Reviewers: sammccall Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D53292 llvm-svn: 344521
-
Sam McCall authored
llvm-svn: 344520
-
Fedor Sergeev authored
Summary: All the PassBuilder::parse interfaces now return descriptive StringError instead of a plain bool. It allows to make -passes/aa-pipeline parsing errors context-specific and thus less confusing. TODO: ideally we should also make suggestions for misspelled pass names, but that requires some extensions to PassBuilder. Reviewed By: philip.pfaffe, chandlerc Differential Revision: https://reviews.llvm.org/D53246 llvm-svn: 344519
-
Sid Manning authored
Differential Revision: https://reviews.llvm.org/D53204 llvm-svn: 344518
-
Aleksandar Beserminji authored
When compiling static executable for micromips, CFI symbols are incorrectly labeled as MICROMIPS, which cause ".eh_frame_hdr refers to overlapping FDEs." error. This patch does not label CFI symbols as MICROMIPS, and FDEs do not overlap anymore. This patch also exposes another bug, which is fixed here: https://reviews.llvm.org/D52985 Differential Revision: https://reviews.llvm.org/D52987 llvm-svn: 344516
-
Aleksandar Beserminji authored
This reverts r344511. llvm-svn: 344515
-
George Rimar authored
This is https://bugs.llvm.org/show_bug.cgi?id=39289. Currently both gold and bfd report errors about invalid options values even with -v/-versions. But LLD does not. This makes complicated to check the options available when LLD is used. Patch makes LLD behavior to be consistent with GNU linkers. Differential revision: https://reviews.llvm.org/D53278 llvm-svn: 344514
-
Sam McCall authored
Summary: See tinyurl.com/clangd-automatic-index for design and goals. Lots of limitations to keep this patch smallish, TODOs everywhere: - no serialization to disk - no changes to dynamic index, which now has a much simpler job - no partitioning of symbols by file to avoid duplication of header symbols - no reindexing of edited files - only a single worker thread - compilation database is slurped synchronously (doesn't scale) - uses memindex, rebuilds after every file (should be dex, periodically) It's not hooked up to ClangdServer/ClangdLSPServer yet: the layering isn't clear (it should really be in ClangdServer, but ClangdLSPServer has all the CDB interactions). Reviewers: ioeric Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D53032 llvm-svn: 344513
-
Simon Pilgrim authored
As I suggested on PR39281, this patch uses PADDL pairwise addition to widen from the vXi8 CTPOP result to the target vector type. This is a blocker for moving more x86 code to generic vector CTPOP expansion (P32655 + D53258) - ARM's vXi64 CTPOP currently expands, which would generate a vXi64 MUL but ARM's custom lowering expands the general MUL case and vectors aren't well handled in LegalizeDAG - improving the CTPOP lowering was a lot easier than fixing the MUL lowering for this one case...... Differential Revision: https://reviews.llvm.org/D53257 llvm-svn: 344512
-
Aleksandar Beserminji authored
When compiling static executable for micromips, CFI symbols are incorrectly labeled as MICROMIPS, which cause ".eh_frame_hdr refers to overlapping FDEs." error. This patch does not label CFI symbols as MICROMIPS, and FDEs do not overlap anymore. This patch also exposes another bug, which is fixed here: https://reviews.llvm.org/D52985 Differential Revision: https://reviews.llvm.org/D52987 llvm-svn: 344511
-
Haojian Wu authored
llvm-svn: 344510
-
Eric Liu authored
Reviewers: sammccall, hokein Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D53284 llvm-svn: 344509
-
Haojian Wu authored
Reviewers: sammccall Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D53019 llvm-svn: 344508
-
Haojian Wu authored
Summary: Previously, SymbolCollector postfilters all references at the end to find all references of interesting symbols. It was incorrect when indxing main AST where we don't see locations of symbol declarations and definitions in the main AST (as those are in preamble AST). The fix is to do earily check during collecting references. Reviewers: sammccall Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D53273 llvm-svn: 344507
-
Nicolai Haehnle authored
Change-Id: I5b64a565f22a8482aa0712488d85e45163ac3d12 llvm-svn: 344506
-
Fedor Sergeev authored
Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
-
Chandler Carruth authored
This removes the primary remaining API producing `TerminatorInst` which will reduce the rate at which code is introduced trying to use it and generally make it much easier to remove the remaining APIs across the codebase. Also clean up some of the stragglers that the previous mechanical update of variables missed. Users of LLVM and out-of-tree code generally will need to update any explicit variable types to handle this. Replacing `TerminatorInst` with `Instruction` (or `auto`) almost always works. Most of these edits were made in prior commits using the perl one-liner: ``` perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g' ``` This also my break some rare use cases where people overload for both `Instruction` and `TerminatorInst`, but these should be easily fixed by removing the `TerminatorInst` overload. llvm-svn: 344504
-
Chandler Carruth authored
are terminators without relying on the specific `TerminatorInst` type. This required cleaning up two users of `InstVisitor`s usage of `TerminatorInst` as well. llvm-svn: 344503
-
Chandler Carruth authored
by `getTerminator()` calls instead be declared as `Instruction`. This is the biggest remaining chunk of the usage of `getTerminator()` that insists on the narrow type and so is an easy batch of updates. Several files saw more extensive updates where this would cascade to requiring API updates within the file to use `Instruction` instead of `TerminatorInst`. All of these were trivial in nature (pervasively using `Instruction` instead just worked). llvm-svn: 344502
-
Chandler Carruth authored
This is the last interesting usage in all of LLVM's headers. The remaining usages in headers are the core typesystem bits (Core.h, instruction types, and InstVisitor) and as the return of `BasicBlock::getTerminator`. The latter is the big remaining API point that I'll remove after mass updates to user code. llvm-svn: 344501
-
Chandler Carruth authored
related code. This is simple as we just need to replace the type and move to the concept of visiting a "terminator" rather than a specific instruction subclass. llvm-svn: 344500
-
Chandler Carruth authored
llvm-svn: 344499
-
Chandler Carruth authored
This requires updating a number of .cpp files to adapt to the new API. I've just systematically updated all uses of `TerminatorInst` within these files te `Instruction` so thta I won't have to touch them again in the future. llvm-svn: 344498
-
Chandler Carruth authored
llvm-svn: 344497
-
Guillaume Chatelet authored
llvm-svn: 344496
-
Chandler Carruth authored
header. NFC. Part of the removal of `TerminatorInst` from the type hierarchy. llvm-svn: 344495
-
Chandler Carruth authored
LLVM APIs. There weren't very many. We still have the instruction visitor, and APIs with TerminatorInst as a return type or an output parameter. llvm-svn: 344494
-
Guillaume Chatelet authored
Summary: This is part one of the change where I simply changed the signature of the functions. More work need to be done to actually produce more than one CodeTemplate per instruction. Reviewers: courbet Subscribers: tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D53209 llvm-svn: 344493
-
Bjorn Pettersson authored
Summary: TwoAddressInstruction pass typically rewrites %1:short = foo %0.sub_lo:long as %1:short = COPY %0.sub_lo:long %1:short = foo %1:short when having tied operands. If there are extra un-tied operands that uses the same reg and subreg, such as the second and third inputs to fie here: %1:short = fie %0.sub_lo:long, %0.sub_hi:long, %0.sub_lo:long then there was a bug which replaced the register %0 also for the un-tied operand, but without changing the subregister indices. So we used to get: %1:short = COPY %0.sub_lo:long %1:short = fie %1, %1.sub_hi:short, %1.sub_lo:short With this fix we instead get: %1:short = COPY %0.sub_lo:long %1:short = fie %1, %0.sub_hi:long, %1 Reviewers: arsenm, JesperAntonsson, kparzysz, MatzeB Reviewed By: MatzeB Subscribers: bjope, kparzysz, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D36224 llvm-svn: 344492
-
Craig Topper authored
llvm-svn: 344490
-
Lang Hames authored
Renames: JITDylib's setFallbackDefinitionGenerator method to setGenerator. DynamicLibraryFallbackGenerator class to DynamicLibrarySearchGenerator. ReexportsFallbackDefinitionGenerator to ReexportsGenerator. llvm-svn: 344489
-
Dean Michael Berris authored
Summary: This change implements a controller for abstracting away the details of what happens when tracing with FDR mode. This controller type allows us to test in isolation the various cases where we're encountering function entry, exit, and other kinds of events we are handling when FDR mode is enabled. This change introduces a number of testing facilities we've needed to better support expressing the conditions we need for the unit tests. We leave some TODOs for moving those utilities into the LLVM project, sitting in the `Testing` library, to make matching conditions on XRay `Trace` instances through googlemock more manageable and declarative. We don't wire in the controller right away, to allow us to incrementally update the implementation(s) as we increase testing coverage of the controller type. There's a need to re-think the way we're managing buffers in a multi-threaded environment, which is more invasive than this implementation. This step in the process allows us to encode our assumptions in the implementation of the controller, and then evolve the buffer queue implementation to support generational buffer management to ensure we can continue to support the cases we're already supporting with the controller. Reviewers: mboerger, eizan Subscribers: mgorny, llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D52588 llvm-svn: 344488
-
Craig Topper authored
Summary: I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that. This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better. In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53107 llvm-svn: 344487
-
Craig Topper authored
We use this instruction to broadcast a single 64-bit value to a v2i64/v2f64 vector. llvm-svn: 344486
-
Craig Topper authored
llvm-svn: 344485
-
- Oct 14, 2018
-
-
Simon Pilgrim authored
llvm-svn: 344484
-
Ayal Zaks authored
Landing this as a separate part of https://reviews.llvm.org/D50480, being a seemingly unrelated change ([LV] Vectorizing loops of arbitrary trip count without remainder under opt for size). llvm-svn: 344483
-
Sid Manning authored
Tests should not assume the linker's name, CLANG_DEFAULT_LINKER could change it. Differential Revision: https://reviews.llvm.org/D53219 llvm-svn: 344482
-
Simon Pilgrim authored
Extends D53148 from v4f64 now that we have test coverage for v16i16/v32i8 shuffles. llvm-svn: 344481
-
Jonathan Metzman authored
Summary: Silence warning when linking unittest binary by not passing -lstdc++ to the linker since it is ignored. Reviewers: morehouse Reviewed By: morehouse Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D53225 llvm-svn: 344480
-