- Jan 24, 2018
-
-
Paul Robinson authored
Patch by Matthew Davis! Differential Revision: https://reviews.llvm.org/D41757 llvm-svn: 323357
-
Geoff Berry authored
Summary: Move reserveRegisterTuples into AMDGPURegisterInfo and use it in R600RegisterInfo::getReservedRegs and R600InstrInfo::reserveIndirectRegisters to ensure that all super registers of reserved registers are also marked as reserved. Before this change, under certain circumstances, the registers %t1_x and %t1_xyzw would be marked as reserved, but %t1_xy and %t1_xyz would not be, leading to the register allocator sometimes assigning a register to %t1_xy, which is invalid since %t1_x is reserved. Reviewers: arsenm, tstellar, MatzeB, qcolombet Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D42448 llvm-svn: 323356
-
Nicolai Haehnle authored
It causes regressions in various OpenGL test suites. Keep the test cases introduced by r321751 as XFAIL, and add a test case for the regression. Change-Id: I90b4cc354f68cebe5fcef1f2422dc8fe1c6d3514 Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36015 llvm-svn: 323355
-
Weiming Zhao authored
Summary: For long shifts, the inlined version takes about 20 instructions on Thumb1. To avoid the code bloat, expand to __aeabi_ calls if target is Thumb1. Reviewers: samparker Reviewed By: samparker Subscribers: samparker, aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42401 llvm-svn: 323354
-
Craig Topper authored
The weirdest being that PEXTRWrr was tagged as a memory operation. llvm-svn: 323353
-
Craig Topper authored
[X86] Adjust names of PINSRW/PEXTRW intructions between MMX/SSE/AVX/AVX512 for consistency and to maybe enable more regular expression compaction in the scheduler models. NFCI llvm-svn: 323352
-
Craig Topper authored
The regexs are treated as a prefix match already so the checking for optional text at the end provides no value. Instead it prevents the binary search optimization in tablegen from kicking in due to the top level question mark. llvm-svn: 323351
-
Sam McCall authored
llvm-svn: 323350
-
Easwaran Raman authored
Summary: This allows relative block frequency of call edges to be passed to the thinlink stage where it will be used to compute synthetic entry counts of functions. Reviewers: tejohnson, pcc Subscribers: mehdi_amini, llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D42212 llvm-svn: 323349
-
Alexey Bataev authored
Summary: If the same value is going to be vectorized several times in the same tree entry, this entry is considered to be a gather entry and cost of this gather is counter as cost of InsertElementInstrs for each gathered value. But we can consider these elements as ShuffleInstr with SK_PermuteSingle shuffle kind. Reviewers: spatel, RKSimon, mkuper, hfinkel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38697 llvm-svn: 323348
-
Sam McCall authored
Reviewers: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42428 llvm-svn: 323347
-
Krzysztof Parzyszek authored
llvm-svn: 323346
-
Artem Belevich authored
NVPTX does not have runtime support necessary for profiling to work and even call arc collection is prohibitively expensive. Furthermore, there's no easy way to collect the samples. NVPTX also does not support global constructors that clang generates if sample/arc collection is enabled. Differential Revision: https://reviews.llvm.org/D42452 llvm-svn: 323345
-
Rafael Espindola authored
This should fix the 32 bit buildbots. llvm-svn: 323344
-
Zvi Rackover authored
Summary: If any vector divisor element is undef, we can arbitrarily choose it be zero which would make the div/rem an undef value by definition. Reviewers: spatel, reames Reviewed By: spatel Subscribers: magabari, llvm-commits Differential Revision: https://reviews.llvm.org/D42485 llvm-svn: 323343
-
Daniel Sanders authored
Summary: `getAction(const InstrAspect &) const` breaks encapsulation by exposing the smaller components that are used to decide how to legalize an instruction. This is a problem because we need to change the implementation of LegalizerInfo so that it's able to describe particular type combinations rather than just cartesian products of types. For example, declaring the following setAction({..., 0, s32}, Legal) setAction({..., 0, s64}, Legal) setAction({..., 1, s32}, Legal) setAction({..., 1, s64}, Legal) currently declares these type combinations as legal: {s32, s32} {s64, s32} {s32, s64} {s64, s64} but we currently have no means to say that, for example, {s64, s32} is not legal. Some operations such as G_INSERT/G_EXTRACT/G_MERGE_VALUES/ G_UNMERGE_VALUES has relationships between the types that are currently described incorrectly. Additionally, G_LOAD/G_STORE currently have no means to legalize non-atomics differently to atomics. The necessary information is in the MMO but we have no way to use this in the legalizer. Similarly, there is currently no way for the register type and the memory type to differ so there is no way to cleanly represent extending-load/truncating-store in a way that can't be broken by optimizers (resulting in illegal MIR). This patch introduces LegalityQuery which provides all the information needed by the legalizer to make a decision on whether something is legal and how to legalize it. Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar, volkan, reames, bogner Reviewed By: bogner Subscribers: bogner, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D42244 llvm-svn: 323342
-
Jonas Devlieghere authored
This allows us to specify the magic number for the DJB hash function. This feature is needed by dsymutil to emit Apple types accelerator table. llvm-svn: 323341
-
Pavel Labath authored
llvm-svn: 323340
-
Jonas Devlieghere authored
This is needed in order to use our StringPool entries in the Apple accelerator tables. As this is NFC we rely on the existing tests for correctness. llvm-svn: 323339
-
Sanjay Patel authored
We're getting bug reports: https://bugs.llvm.org/show_bug.cgi?id=35807 https://bugs.llvm.org/show_bug.cgi?id=35840 https://bugs.llvm.org/show_bug.cgi?id=36045 ...where we blow up the stack in value tracking because other passes are sending in selects that have an operand that is itself the select. We don't currently have a reliable way to avoid analyzing dead code that may take non-standard forms, so bail out when things go too far. This mimics the recursion depth limitations in other parts of value tracking. Unfortunately, this pushes the underlying problems for other passes (jump-threading, simplifycfg, correlated-propagation) into hiding. If someone wants to uncover those again, the first draft of this patch on Phab would do that (it would assert rather than bail out). Differential Revision: https://reviews.llvm.org/D42442 llvm-svn: 323331
-
Hans Wennborg authored
llvm-svn: 323330
-
Zvi Rackover authored
Add cases with vector non-splat pow2 contant divider. llvm-svn: 323329
-
Simon Pilgrim authored
llvm-svn: 323328
-
Amjad Aboud authored
llvm-svn: 323326
-
Pablo Barrio authored
Summary: Loads/stores of some NEON vector types are promoted to other vector types with different lane sizes but same vector size. This is not a problem in little-endian but, when in big-endian, it requires additional byte reversals required to preserve the lane ordering while keeping the right endianness of the data inside each lane. For example: %1 = load <4 x half>, <4 x half>* %p results in the following assembly: ld1 { v0.2s }, [x1] rev32 v0.4h, v0.4h This patch changes the promotion of these loads/stores so that the actual vector load/store (LD1/ST1) takes care of the endianness correctly and there is no need for further byte reversals. The previous code now results in the following assembly: ld1 { v0.4h }, [x1] Reviewers: olista01, SjoerdMeijer, efriedma Reviewed By: efriedma Subscribers: aemerson, rengolin, javed.absar, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D42235 llvm-svn: 323325
-
Krzysztof Parzyszek authored
llvm-svn: 323324
-
Sander de Smalen authored
Summary: This patch implements the codegen of DWARF debug info for non-constant 'count' fields for DISubrange. This is patch [2/3] in a series to extend LLVM's DISubrange Metadata node to support debugging of C99 variable length arrays and vectors with runtime length like the Scalable Vector Extension for AArch64. It is also a first step towards representing more complex cases like arrays in Fortran. Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: fhahn, aemerson, rengolin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41696 llvm-svn: 323323
-
Mikhail Maltsev authored
Summary: Currently when a regular expression contains an invalid character class name std::regex constructors throw an std::regex_error with std::regex_constants::error_brack code. This patch changes the code to std::regex_constants::error_ctype and adds a test. Reviewers: EricWF, mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42291 llvm-svn: 323322
-
Amjad Aboud authored
Combine expression patterns to form expressions with fewer, simple instructions. This pass does not modify the CFG. For example, this pass reduce width of expressions post-dominated by TruncInst into smaller width when applicable. It differs from instcombine pass in that it contains pattern optimization that requires higher complexity than the O(1), thus, it should run fewer times than instcombine pass. Differential Revision: https://reviews.llvm.org/D38313 llvm-svn: 323321
-
Simon Pilgrim authored
[X86][SSE] Avoid calls to combineX86ShufflesRecursively that can't combine to target shuffles (PR32037) Don't bother making recursive calls to combineX86ShufflesRecursively if we have more shuffle source operands than will be combined together with the remaining recursive depth. See https://bugs.llvm.org/show_bug.cgi?id=32037#c26 and https://bugs.llvm.org/show_bug.cgi?id=32037#c27 for the reduction in compile times from this patch. Differential Revision: https://reviews.llvm.org/D42378 llvm-svn: 323320
-
Krasimir Georgiev authored
Summary: Commonly string literals in protos are already multiline, so breaking them further is undesirable. Reviewers: djasper Reviewed By: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D42373 llvm-svn: 323319
-
Malcolm Parsons authored
llvm-svn: 323318
-
Sander de Smalen authored
(and also slightly reformatted the related lines to look better in the rendered HTML) llvm-svn: 323317
-
Malcolm Parsons authored
llvm-svn: 323316
-
Martin Storsjö authored
This makes sure that the last cache line gets invalidated properly. This matches the example code at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABJDBHI.html, and also matches what libgcc does. Differential Revision: https://reviews.llvm.org/D42196 llvm-svn: 323315
-
Igor Laevsky authored
Differential Revision: https://reviews.llvm.org/D42410 llvm-svn: 323314
-
Sander de Smalen authored
Summary: This patch extends the DISubrange 'count' field to take either a (signed) constant integer value or a reference to a DILocalVariable or DIGlobalVariable. This is patch [1/3] in a series to extend LLVM's DISubrange Metadata node to support debugging of C99 variable length arrays and vectors with runtime length like the Scalable Vector Extension for AArch64. It is also a first step towards representing more complex cases like arrays in Fortran. Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: rnk, probinson, fhahn, aemerson, rengolin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41695 llvm-svn: 323313
-
Sven van Haastregt authored
For the included test case, the DAG transformation concat_vectors(scalar, undef) -> scalar_to_vector(sclr) would attempt to create a v2i32 vector for a v9i8 concat_vector. Bail out to avoid creating a bitcast with mismatching sizes later on. Differential Revision: https://reviews.llvm.org/D42379 llvm-svn: 323312
-
David Chisnall authored
Summary: This is the first attempt to write down a guideline on adding exception handling support for a target. The content basically bases on the discussion on [1]. If you guys know who is exception handling expert, please add him as the reviewer. Thanks. [1] http://lists.llvm.org/pipermail/llvm-dev/2018-January/120405.html Reviewers: t.p.northover, theraven, nemanjai Reviewed By: theraven Subscribers: sdardis, llvm-commits Differential Revision: https://reviews.llvm.org/D42178 llvm-svn: 323311
-
Raphael Isemann authored
Summary: The new test is now in the right directory with the other ASTVisitor tests and uses now the provided TestVisitor framework. Subscribers: hintonda, v.g.vassilev, klimek, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37557 llvm-svn: 323310
-