summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Remove custom handling for extloads from LowerLoad.Craig Topper2019-08-091-183/+1
| | | | | | We don't appear to need this with widening legalization. llvm-svn: 368479
* [CodeGen] Require a name for a block addr targetBill Wendling2019-08-093-1/+122
| | | | | | | | | | | | | | | | | | | Summary: A block address may be used in inline assembly. In which case it requires a name so that the asm parser has something to parse. Creating a name for every block address is a large hammer, but is necessary because at the point when a temp symbol is created we don't necessarily know if it's used in inline asm. This ensures that it exists regardless. Reviewers: nickdesaulniers, craig.topper Subscribers: nathanchance, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65352 llvm-svn: 368478
* [MC] Don't recreate a label if it's already usedBill Wendling2019-08-097-9/+124
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch keeps track of MCSymbols created for blocks that were referenced in inline asm. It prevents creating a new symbol which doesn't refer to the block. Inline asm may have a reference to a label. The asm parser however doesn't recognize it as a label and tries to create a new symbol. The result being that instead of the original symbol (e.g. ".Ltmp0") the parser replaces it in the inline asm with the new one (e.g. ".Ltmp00") without updating it in the symbol table. So the machine basic block retains the "old" symbol (".Ltmp0"), but the inline asm uses the new one (".Ltmp00"). Reviewers: nickdesaulniers, craig.topper Subscribers: nathanchance, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65304 llvm-svn: 368477
* [sanitizers] MSVC warning disable for clean buildMatthew G McGovern2019-08-095-0/+53
| | | | | | - https://reviews.llvm.org/D66023 llvm-svn: 368476
* Don't diagnose errors when a file matches an include componentReid Kleckner2019-08-094-1/+7
| | | | | | | | | This regressed in r368322, and was reported as PR42948 and on the mailing list. The fix is to ignore the specific error code for this case. The problem doesn't seem to reproduce on Windows, where a different error code is used instead. llvm-svn: 368475
* Update test to explicity test with -fintegrated-as and -fno-integrated-as ↵Douglas Yung2019-08-091-7/+39
| | | | | | | | | | and to expect warnings when appropriate. Reviewed by: thakis Differential Revision: https://reviews.llvm.org/D65974 llvm-svn: 368474
* [Docs][llvm-strip] Fix an indentation issue.Michael Pozulp2019-08-091-1/+1
| | | | llvm-svn: 368473
* Revert "[asan_symbolize] Fix bug where the frame counter was not incremented."Mitch Phillips2019-08-093-88/+4
| | | | | | | | | This reverts commit 52a36fae2a3f8560a5be690a67304db5edafc3fe. This commit broke the sanitizer_android buildbot. See comments at https://reviews.llvm.org/rL368373 for more details. llvm-svn: 368472
* CodeGen: ensure 8-byte aligned String Swift CF ABISaleem Abdulrasool2019-08-092-1/+10
| | | | | | | | | CFStrings should be 8-byte aligned when built for the Swift CF runtime ABI as the atomic CF info field must be properly aligned. This is a problem on 32-bit platforms which would give the structure 4-byte alignment rather than 8-byte alignment. llvm-svn: 368471
* gn build: Merge r368432.Peter Collingbourne2019-08-091-0/+1
| | | | llvm-svn: 368470
* gn build: Merge r368439.Peter Collingbourne2019-08-091-0/+1
| | | | llvm-svn: 368469
* gn build: Merge r368402.Peter Collingbourne2019-08-091-0/+1
| | | | llvm-svn: 368468
* gn build: Merge r368392.Peter Collingbourne2019-08-091-0/+3
| | | | llvm-svn: 368467
* gn build: Merge r368358.Peter Collingbourne2019-08-092-0/+17
| | | | llvm-svn: 368466
* [libomptarget] Remove duplicate RTLRequiresFlags per deviceJonas Hahnfeld2019-08-095-21/+14
| | | | | | | | | | | | | | | We have one global RTLs.RequiresFlags, I don't see a need to make a copy per device that the runtime manages. This was problematic anyway because the copy happened during the first __tgt_register_lib(). This made it impossible to call __tgt_register_requires() from normal user funtions for testing. Hence, this change also fixes unified_shared_memory/shared_update.c for older versions of Clang that don't call __tgt_register_requires() before __tgt_register_lib(). Differential Revision: https://reviews.llvm.org/D66019 llvm-svn: 368465
* [Docs][llvm-strip] Add help text to llvm-strip rst docMichael Pozulp2019-08-092-16/+167
| | | | | | | | | | | | | | | | Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=42383 Reviewers: jhenderson, alexshap, rupprecht Reviewed By: jhenderson Subscribers: wolfgangp, jakehehrlich, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65384 llvm-svn: 368464
* Revert Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath2019-08-092-79/+10
| | | | | | This reverts r368454 (git commit 7c3c8ba8daf40534e09f6fe8701b723e25e4e2dc) llvm-svn: 368463
* Revert Fix a build bot failure and multiple warnings instances for range ↵Gabor Horvath2019-08-092-13/+3
| | | | | | | | base for loops This reverts r368459 (git commit 2bf522aea62e4fb653cacb68072167d25149099e) llvm-svn: 368462
* [libFuzzer] Merge: print stats after reading the output corpus dir.Max Moroz2019-08-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The purpose is to be able to extract the number of new edges added to the original (i.e. output) corpus directory after doing the merge. Use case example: in ClusterFuzz, we do merge after every fuzzing session, to avoid uploading too many corpus files, and we also record coverage stats at that point. Having a separate line indicating stats after reading the initial output corpus directory would make the stats extraction easier for both humans and parsing scripts. Context: https://github.com/google/clusterfuzz/issues/802. Reviewers: morehouse, hctim Reviewed By: hctim Subscribers: delcypher, #sanitizers, llvm-commits, kcc Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66020 llvm-svn: 368461
* [clang-format] Add link to source code in file definitionsDiego Astiazaran2019-08-0913-101/+238
| | | | | | | | | | | | | Two command line options have been added to clang-doc. --repository=<string> - URL of repository that hosts code; used for links to definition locations. --source-root=<string> - Directory where processed files are stored. Links to definition locations will only be generated if the file is in this dir. If the file is in the source-root and a repository options is passed; a link to the source code will be rendered by the HTML generator. Differential Revision: https://reviews.llvm.org/D65483 llvm-svn: 368460
* Fix a build bot failure and multiple warnings instances for range base for loopsGabor Horvath2019-08-092-3/+13
| | | | llvm-svn: 368459
* [TableGen] Add "InitValue": Handle operands with set bit values in decoder ↵Daniel Sanders2019-08-092-4/+53
| | | | | | | | | | | | | | | | | | | | | | | | | methods Summary: The problem: When an operand had bits explicitly set to "1" (as in the InitValue.td test case attached), the decoder was ignoring those bits, and the DecoderMethod was receiving an input where the bits were still zero. The solution: We added an "InitValue" variable that stores the initial value of the operand based on what bits were explicitly initialized to 1 in TableGen code. The generated decoder code then uses that initial value to initialize the "tmp" variable, then calls fieldFromInstruction to read the values for the remaining bits that were left unknown in TableGen. This is mainly useful when there are variations of an instruction that differ based on what bits are set in the operands, since this change makes it possible to access those bits in a DecoderMethod. The DecoderMethod can use those bits to know how to handle the input. Patch by Nicolas Guillemot Reviewers: craig.topper, dsanders, fhahn Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D63741 llvm-svn: 368458
* [InstCombine] Refactor optimizeExp2() (NFC)Evandro Menezes2019-08-091-31/+19
| | | | | | | Refactor `LibCallSimplifier::optimizeExp2()` to use the new `emitBinaryFloatFnCall()` version that fetches the function name from TLI. llvm-svn: 368457
* Rename PCH/leakfiles test so it runs on bots.Sam McCall2019-08-091-0/+0
| | | | llvm-svn: 368455
* Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath2019-08-092-10/+79
| | | | | | Differential Revision: https://reviews.llvm.org/D65127 llvm-svn: 368454
* [Transforms] Add a emitBinaryFloatFnCall() version that fetches the function ↵Evandro Menezes2019-08-092-9/+42
| | | | | | | | | | name from TLI Add the counterpart to a similar function for single operands. Differential revision: https://reviews.llvm.org/D65976 llvm-svn: 368453
* [Transforms] Fix comments for hasFloatFn() and getFloatFnName() (NFC)Evandro Menezes2019-08-091-2/+2
| | | | llvm-svn: 368452
* Print reasonable representations of type names in llvm-nm, readelf and readobjSunil Srivastava2019-08-095-35/+94
| | | | | | | | | | | For type values that do not have proper names, print reasonable representation in llvm-nm, llvm-readobj and llvm-readelf, matching GNU tools.s Fixes PR41713. Differential Revision: https://reviews.llvm.org/D65537 llvm-svn: 368451
* Title: Improve Loop Cache Analysis LIT tests.Whitney Tsang2019-08-095-16/+16
| | | | | | | Summary: Make LIT tests unsensitive to analysis output order. Authored By: etiotto llvm-svn: 368450
* [Transforms] Rename hasUnaryFloatFn() and getUnaryFloatFn() (NFC)Evandro Menezes2019-08-094-29/+24
| | | | | | Rename `hasUnaryFloatFn()` to `hasFloatFn()` and `getUnaryFloatFn()` to `getFloatFnName()`. llvm-svn: 368449
* [compiler-rt] FuzzedDataProvider: use C++ headers only instead of a C/C++ mix.Max Moroz2019-08-091-4/+3
| | | | | | | | | | | | | | Reviewers: Dor1s Reviewed By: Dor1s Subscribers: dberris, delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66017 llvm-svn: 368448
* [NFC] Added tests for D65898David Bolvansky2019-08-091-0/+24
| | | | llvm-svn: 368447
* More warnings regarding gsl::Pointer and gsl::Owner attributesGabor Horvath2019-08-093-20/+74
| | | | | | Differential Revision: https://reviews.llvm.org/D65120 llvm-svn: 368446
* [AArch64][x86] add tests for pessimization of expression with X*2.0 ↵Sanjay Patel2019-08-092-0/+58
| | | | | | (PR32939); NFC llvm-svn: 368445
* [lldb][NFC] Assert on invalid cursors positions when creating CompletionRequestRaphael Isemann2019-08-091-0/+1
| | | | | | Before we just triggered undefined behavior on invalid positions. llvm-svn: 368444
* [DAGCombiner] remove redundant fold for X*1.0; NFCSanjay Patel2019-08-091-4/+0
| | | | | | | | | This is handled at node creation time (similar to X/1.0) after: rL357029 (no fast-math-flags needed) llvm-svn: 368443
* [lldb][NFC] Remove unused IRForTarget::BuildRelocationRaphael Isemann2019-08-092-36/+0
| | | | llvm-svn: 368442
* [MachinePipeliner] Avoid indeterminate order in FuncUnitSorterJinsong Ji2019-08-092-1/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
* [sanitizer] Update symbolizer/scripts/global_symbols.txtBenjamin Kramer2019-08-091-0/+5
| | | | llvm-svn: 368440
* Title: Loop Cache AnalysisWhitney Tsang2019-08-0911-0/+1437
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement a new analysis to estimate the number of cache lines required by a loop nest. The analysis is largely based on the following paper: Compiler Optimizations for Improving Data Locality By: Steve Carr, Katherine S. McKinley, Chau-Wen Tseng http://www.cs.utexas.edu/users/mckinley/papers/asplos-1994.pdf The analysis considers temporal reuse (accesses to the same memory location) and spatial reuse (accesses to memory locations within a cache line). For simplicity the analysis considers memory accesses in the innermost loop in a loop nest, and thus determines the number of cache lines used when the loop L in loop nest LN is placed in the innermost position. The result of the analysis can be used to drive several transformations. As an example, loop interchange could use it determine which loops in a perfect loop nest should be interchanged to maximize cache reuse. Similarly, loop distribution could be enhanced to take into consideration cache reuse between arrays when distributing a loop to eliminate vectorization inhibiting dependencies. The general approach taken to estimate the number of cache lines used by the memory references in the inner loop of a loop nest is: Partition memory references that exhibit temporal or spatial reuse into reference groups. For each loop L in the a loop nest LN: a. Compute the cost of the reference group b. Compute the 'cache cost' of the loop nest by summing up the reference groups costs For further details of the algorithm please refer to the paper. Authored By: etiotto Reviewers: hfinkel, Meinersbur, jdoerfert, kbarton, bmahjour, anemet, fhahn Reviewed By: Meinersbur Subscribers: reames, nemanjai, MaskRay, wuzish, Hahnfeld, xusx595, venkataramanan.kumar.llvm, greened, dmgreen, steleman, fhahn, xblvaOO, Whitney, mgorny, hiraditya, mgrang, jsji, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D63459 llvm-svn: 368439
* [X86][SSE] Swap X86ISD::BLENDV inputs with an inverted selection mask (PR42825)Simon Pilgrim2019-08-093-21/+19
| | | | | | | | As discussed on PR42825, if we are inverting the selection mask we can just swap the inputs and avoid the inversion. Differential Revision: https://reviews.llvm.org/D65522 llvm-svn: 368438
* [GlobalOpt] prevent crashing on large integer types (PR42932)Sanjay Patel2019-08-092-2/+27
| | | | | | | | | | | This is a minimal fix (copy the predicate for the assert) to prevent the crashing seen in: https://bugs.llvm.org/show_bug.cgi?id=42932 ...when converting a constant integer of arbitrary width to uint64_t. Differential Revision: https://reviews.llvm.org/D65970 llvm-svn: 368437
* [MCA] Fix MSVC 19.16 build with libc++Andrea Di Biagio2019-08-091-2/+3
| | | | | | | | | | | | MSVC (19.16) wants to see the definition of Instruction in `std::pair<unsigned, const Instruction &> SourceRef` to decide if it is assignable. Patch by Orivej Desh. Differential Revision: https://reviews.llvm.org/D65844 llvm-svn: 368436
* [llvm-readelf]Print filename for multiple inputs and fix formatting regressionJames Henderson2019-08-094-7/+51
| | | | | | | | | | | | | | | | | | | This patch addresses two closely related bugs: https://bugs.llvm.org/show_bug.cgi?id=42930 and https://bugs.llvm.org/show_bug.cgi?id=42931. GNU readelf prints the file name for every input unless there is only one input and that input is not an archive. This patch adds the printing for multiple inputs. A previous change did it for archives, but introduced a regression with GNU compatibility for single-output formatting, resulting in a spurious initial blank line. This is fixed in this patch too. Reviewed by: grimar, MaskRay Differential Revision: https://reviews.llvm.org/D65953 llvm-svn: 368435
* [clangd] Added highlighting for constructor initializers.Johan Vikstrom2019-08-092-0/+26
| | | | | | | | | | | | | | Summary: Constructor initializers were not being highlighted. This adds highlighting for them by using TraverseConstructorInitializer. Uses the Traverse* because there is no visit for CXXCtorInitializer. Reviewers: hokein, ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66001 llvm-svn: 368434
* [Mips][Codegen] Fix fast-isel mixing of FGR64 and AFGR64 registersSimon Atanasyan2019-08-092-2/+37
| | | | | | | | | | | | Fast-isel was picking AFGR64 register class for processing call arguments when +fp64 options was used. We simply check is option +fp64 is used and pick appropriate register. Patch by Mirko Brkusanin. Differential Revision: https://reviews.llvm.org/D65886 llvm-svn: 368433
* [MCA] Add flag -show-encoding to llvm-mca.Andrea Di Biagio2019-08-098-17/+274
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flag -show-encoding enables the printing of instruction encodings as part of the the instruction info view. Example (with flags -mtriple=x86_64-- -mcpu=btver2): Instruction Info: [1]: #uOps [2]: Latency [3]: RThroughput [4]: MayLoad [5]: MayStore [6]: HasSideEffects (U) [7]: Encoding Size [1] [2] [3] [4] [5] [6] [7] Encodings: Instructions: 1 2 1.00 4 c5 f0 59 d0 vmulps %xmm0, %xmm1, %xmm2 1 4 1.00 4 c5 eb 7c da vhaddps %xmm2, %xmm2, %xmm3 1 4 1.00 4 c5 e3 7c e3 vhaddps %xmm3, %xmm3, %xmm4 In this example, column Encoding Size is the size in bytes of the instruction encoding. Column Encodings reports the actual instruction encodings as byte sequences in hex (objdump style). The computation of encodings is done by a utility class named mca::CodeEmitter. In future, I plan to expose the CodeEmitter to the instruction builder, so that information about instruction encoding sizes can be used by the simulator. That would be a first step towards simulating the throughput from the decoders in the hardware frontend. Differential Revision: https://reviews.llvm.org/D65948 llvm-svn: 368432
* [AArch64] Set pref. func. align to 8 bytes on Neoverse E1 & Cortex-A65Pablo Barrio2019-08-092-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The Arm Neoverse E1 and Cortex-A65 Software Optimization Guide [1][2], Section "4.7 Branch instruction alignment" state: "It is preferable for branch targets, including subroutine entry points, to be placed on aligned 64-bit boundaries to maximize instruction fetch efficiency." This patch sets the preferred function alignment on Neoverse E1 and Cortex-A65 to 2^3=8B. This was already the case in some Cortex-A CPUs such as Cortex-A53. [1] https://developer.arm.com/docs/swog466751/latest/arm-neoversetm-e1-core-software-optimization-guide [2] https://developer.arm.com/docs/swog010045/latest/arm-cortex-a65-core-software-optimization-guide Reviewers: dmgreen, fhahn, samparker Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65937 llvm-svn: 368431
* [llvm-readobj] - Remove `error(llvm::Expected<T> &&E)`George Rimar2019-08-093-8/+7
| | | | | | | | | | This is a bit strange method. It works like a unwrapOrError, but named error. It does not report an Input name. I removed it. Differential revision: https://reviews.llvm.org/D66000 llvm-svn: 368430
* [clangd] Use raw rename functions to implement the rename.Haojian Wu2019-08-092-62/+47
| | | | | | | | | | | | | | | | | | | | | | | Summary: The API provided by refactoring lib doesn't provide enough flexibility to get clangd's rename to behave as we expect. Instead, we replace it with the low-level rename functions, which give us more control. Bonus: - performance, previously we visit the TU to find all occurrences, now we just visit top-level decls from main file; - fix a bug where we wrongly filter out the main file replacement due to the different relative/absolute file path; Reviewers: sammccall Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65936 llvm-svn: 368429
OpenPOWER on IntegriCloud