summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* [OpenMP][IR-Builder] Introduce "pragma omp parallel" code generationJohannes Doerfert2019-12-252-7/+313
| | | | | | | | | This patch combines the `emitParallel` logic prototyped in D61953 with the OpenMPIRBuilder (D69785) and introduces `CreateParallel`. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D70109
* [OpenMP][IR-Builder] Introduce the finalization stackJohannes Doerfert2019-12-251-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | As a permanent and generic solution to the problem of variable finalization (destructors, lastprivate, ...), this patch introduces the finalization stack. The objects on the stack describe (1) the (structured) regions the OpenMP-IR-Builder is currently constructing, (2) if these are cancellable, and (3) the callback that will perform the finalization (=cleanup) when necessary. As the finalization can be necessary multiple times, at different source locations, the callback takes the position at which code is currently generated. This position will also encode the destination of the "region exit" block *iff* the finalization call was issues for a region generated by the OpenMPIRBuilder. For regions generated through the old Clang OpenMP code geneneration, the "region exit" is determined by Clang inside the finalization call instead (see getOMPCancelDestination). As a first user, the parallel + cancel barrier interaction is changed. In contrast to the temporary solution before, the barrier generation in Clang does not need to be aware of the "CancelDestination" block. Instead, the finalization callback is and, as described above, later even that one does not need to be. D70109 will be updated to use this scheme. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D70258
* [Support] Fix behavior of StringRef::count with overlapping occurrences, add ↵Johannes Doerfert2019-12-241-0/+7
| | | | | | | | | | | | | | | | | | tests Summary: Fix the behavior of StringRef::count(StringRef) to not count overlapping occurrences, as is stated in the documentation. Fixes bug https://bugs.llvm.org/show_bug.cgi?id=44072 I added Krzysztof Parzyszek to review this change because a use of this function in HexagonInstrInfo::getInlineAsmLength might depend on the overlapping-behavior. I don't have enough domain knowledge to tell if this change could break anything there. All other uses of this method in LLVM (besides the unit tests) only use single-character search strings. In those cases, search occurrences can not overlap anyway. Patch by Benno (@Bensge) Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D70585
* reland "[DebugInfo] Support to emit debugInfo for extern variables"Yonghong Song2019-12-221-1/+1
| | | | | | | | | | | | | Commit d77ae1552fc21a9f3877f3ed7e13d631f517c825 ("[DebugInfo] Support to emit debugInfo for extern variables") added deebugInfo for extern variables for BPF target. The commit is reverted by 891e25b02d760d0de18c7d46947913b3166047e7 as the committed tests using %clang instead of %clang_cc1 causing test failed in certain scenarios as reported by Reid Kleckner. This patch fixed the tests by using %clang_cc1. Differential Revision: https://reviews.llvm.org/D71818
* Revert "[DebugInfo] Support to emit debugInfo for extern variables"Reid Kleckner2019-12-221-1/+1
| | | | | | | This reverts commit d77ae1552fc21a9f3877f3ed7e13d631f517c825. The tests committed along with this change do not pass, and should be changed to use %clang_cc1.
* Fix Wpedantic 'extra semicolon' warning. NFC.Simon Pilgrim2019-12-211-1/+1
|
* Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysrootAdrian Prantl2019-12-201-1/+1
| | | | | | | | | | | | This is a purely cosmetic change that is NFC in terms of the binary output. I bugs me that I called the attribute DW_AT_LLVM_isysroot since the "i" is an artifact of GCC command line option syntax (-isysroot is in the category of -i options) and doesn't carry any useful information otherwise. This attribute only appears in Clang module debug info. Differential Revision: https://reviews.llvm.org/D71722
* [ARM][MVE] Tail predicate bottom/top muls.Sam Parker2019-12-201-1/+24
| | | | | | Add VMULL and VQDMULL variants to our tail predication white list. Differential Revision: https://reviews.llvm.org/D71465
* llvm-cxxmap: fix support for remapping non-mangled names.Richard Smith2019-12-181-1/+14
| | | | | | | Remappings involving extern "C" names were already supported in the context of <local-name>s, but this support didn't work for remapping the complete mangling itself. (Eg, we would remap X<foo> but not foo itself, if foo is an extern "C" function.)
* [llvm-exegesis][NFC] internal changesGuillaume Chatelet2019-12-183-41/+55
| | | | | | | | | | | | | | Summary: BitVectors are now cached to lower memory utilization. Instructions have reference semantics. Reviewers: courbet Subscribers: sdardis, tschuett, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71653
* [LoopUtils] Updated deleteDeadLoop() to handle loop nest.Whitney Tsang2019-12-182-0/+91
| | | | | | | | | Reviewer: kariddi, sanjoy, reames, Meinersbur, bmahjour, etiotto, kbarton Reviewed By: Meinersbur Subscribers: mgorny, hiraditya, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D70939
* [FPEnv] IRBuilder support for constrained sitofp/uitofp.Kevin P. Neal2019-12-171-0/+10
|
* Revert "[LoopUtils] Updated deleteDeadLoop() to handle loop nest."Whitney Tsang2019-12-172-91/+0
| | | | | This reverts commit cd09fee3d63296dd2df0bbb1fae363ca9f311d44. This reverts commit c066ff11d84a7797503ad5a44c4129136926dc85.
* [LoopUtils] Updated deleteDeadLoop() to handle loop nest.Whitney Tsang2019-12-171-0/+90
| | | | | | | | | Reviewer: kariddi, sanjoy, reames, Meinersbur, bmahjour, etiotto, kbarton Reviewed By: Meinersbur Subscribers: mgorny, hiraditya, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D70939
* [LoopUtils] Updated deleteDeadLoop() to handle loop nest.Whitney Tsang2019-12-171-0/+1
| | | | | | | | | Reviewer: kariddi, sanjoy, reames, Meinersbur, bmahjour, etiotto, kbarton Reviewed By: Meinersbur Subscribers: mgorny, hiraditya, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D70939
* [llvm-exegesis][mips] Add SnippetGeneratorTest unit testMiloš Stojanović2019-12-162-0/+112
| | | | | | | Test latency with explicit register dependency, without and with forbidden registers. Differential Revision: https://reviews.llvm.org/D71471
* [llvm-exegesis] Set up AsmTargetStreamer in readSnippetsGuillaume Chatelet2019-12-161-0/+7
| | | | | | | | | | | | Summary: This is a follow up on D71137 properly setting up the AsmTargetStreamer prior to AsmParser::Run call. Reviewers: courbet, mstojanovic Subscribers: tschuett, mikhail.ramalho, llvm-commits, petarj, atanasyan Tags: #llvm Differential Revision: https://reviews.llvm.org/D71468
* [Legalizer] Making artifact combining order-independentRoman Tereshin2019-12-131-17/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Legalization algorithm is complicated by two facts: 1) While regular instructions should be possible to legalize in an isolated, per-instruction, context-free manner, legalization artifacts can only be eliminated in pairs, which could be deeply, and ultimately arbitrary nested: { [ () ] }, where which paranthesis kind depicts an artifact kind, like extend, unmerge, etc. Such structure can only be fully eliminated by simple local combines if they are attempted in a particular order (inside out), or alternatively by repeated scans each eliminating only one innermost pair, resulting in O(n^2) complexity. 2) Some artifacts might in fact be regular instructions that could (and sometimes should) be legalized by the target-specific rules. Which means failure to eliminate all artifacts on the first iteration is not a failure, they need to be tried as instructions, which may produce more artifacts, including the ones that are in fact regular instructions, resulting in a non-constant number of iterations required to finish the process. I trust the recently introduced termination condition (no new artifacts were created during as-a-regular-instruction-retrial of artifacts not eliminated on the previous iteration) to be efficient in providing termination, but only performing the legalization in full if and only if at each step such chains of artifacts are successfully eliminated in full as well. Which is currently not guaranteed, as the artifact combines are applied only once and in an arbitrary order that has to do with the order of creation or insertion of artifacts into their worklist, which is a no particular order. In this patch I make a small change to the artifact combiner, making it to re-insert into the worklist immediate (modulo a look-through copies) artifact users of each vreg that changes its definition due to an artifact combine. Here the first scan through the artifacts worklist, while not being done in any guaranteed order, only needs to find the innermost pair(s) of artifacts that could be immediately combined out. After that the process follows def-use chains, making them shorter at each step, thus combining everything that can be combined in O(n) time. Reviewers: volkan, aditya_nandakumar, qcolombet, paquette, aemerson, dsanders Reviewed By: aditya_nandakumar, paquette Tags: #llvm Differential Revision: https://reviews.llvm.org/D71448
* [Legalizer] Refactoring out legalizeMachineFunctionRoman Tereshin2019-12-132-0/+80
| | | | | | | | and introducing new unittests/CodeGen/GlobalISel/LegalizerTest.cpp relying on it to unit test the entire legalizer algorithm (including the top-level main loop). See also https://reviews.llvm.org/D71448
* Revert "[VectorUtils] Introduce the Vector Function Database (VFDatabase)."Francesco Petrogalli2019-12-131-21/+3
| | | | | | | | | This reverts commit 0be81968a283fd4161cb9ac9748d5ed200926292. The VFDatabase needs some rework to be able to handle vectorization and subsequent scalarization of intrinsics in out-of-tree versions of the compiler. For more details, see the discussion in https://reviews.llvm.org/D67572.
* [llvm-exegesis][mips] Add BenchmarkResultTest unit testMiloš Stojanović2019-12-132-0/+142
| | | | | | | | Test writing and reading benchmark instructions to and from disc, and check calculations of min, max and avg values from a list of benchmark measures. Differential Revision: https://reviews.llvm.org/D71265
* [ARM][MVE] Make VPT invalid for tail predicationSam Parker2019-12-131-22/+0
| | | | | | | | | We've been marking VPT incompatible instructions as invalid for tail predication too, though this may not strictly be true. VPT are incompatible and, unless its the first predicate def in a loop, they shouldn't be compatible for tail predication either. Differential Revision: https://reviews.llvm.org/D71410
* Rename LoopInfo::isRotated() to LoopInfo::isRotatedForm().Kit Barton2019-12-121-17/+17
| | | | | | This patch renames the LoopInfo::isRotated() method to LoopInfo::isRotatedForm() to make it clear that the method checks whether the loop is in rotated form, not whether the loop has been rotated by the LoopRotation pass.
* [IR] Split out target specific intrinsic enums into separate headersReid Kleckner2019-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | This has two main effects: - Optimizes debug info size by saving 221.86 MB of obj file size in a Windows optimized+debug build of 'all'. This is 3.03% of 7,332.7MB of object file size. - Incremental step towards decoupling target intrinsics. The enums are still compact, so adding and removing a single target-specific intrinsic will trigger a rebuild of all of LLVM. Assigning distinct target id spaces is potential future work. Part of PR34259 Reviewers: efriedma, echristo, MaskRay Reviewed By: echristo, MaskRay Differential Revision: https://reviews.llvm.org/D71320
* [ADT] Fix SmallDenseMap assertion with large InlineBucketsNikita Popov2019-12-111-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes issue encountered in D56362, where I tried to use a SmallSetVector<Instruction*, 128> with an excessively large number of inline elements. This triggers an "Must allocate more buckets than are inline" assertion inside allocateBuckets() under certain usage patterns. The issue is as follows: The grow() method is used either to grow the map, or to rehash it and remove tombstones. The latter is done if the fraction of empty (non-used, non-tombstone) elements is below 1/8. In this case grow() is invoked with the current number of buckets. This is currently incorrectly handled for dense maps using the small rep. The current implementation will switch them over to the large rep, which violates the invariant that the large rep is only used if there are more than InlineBuckets buckets. This patch fixes the issue by staying in the small rep and only moving the buckets. An alternative, if we do want to switch to the large rep in this case, would be to relax the assertion in allocateBuckets(). Differential Revision: https://reviews.llvm.org/D56455
* [OpenMP] Introduce the OpenMP-IR-BuilderJohannes Doerfert2019-12-113-0/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the initial patch for the OpenMP-IR-Builder, as discussed on the mailing list ([1] and later) and at the US Dev Meeting'19. The design is similar to D61953 but: - in a non-WIP status, with proper documentation and working. - using a OpenMPKinds.def file to manage lists of directives, runtime functions, types, ..., similar to the current Clang implementation. - restricted to handle only (simple) barriers, to implement most `#pragma omp barrier` directives and most implicit barriers. - properly hooked into Clang to be used if possible (D69922). - compatible with the remaining code generation. Parts have been extracted into D69853. The plan is to have multiple people working on moving logic from Clang here once the initial scaffolding (=this patch) landed. [1] http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: mgorny, hiraditya, bollu, guansong, jfb, cfe-commits, llvm-commits, penzn, ppenzin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69785
* [VFS] Disable check for ../foo on WindowsJonas Devlieghere2019-12-111-0/+2
| | | | | I'm not sure how .. is resolved on Windows. Disable it for now to make the bots happy again.
* [StringRef] Test all default characters in unit testJonas Devlieghere2019-12-111-0/+4
| | | | | The default characters for trim, ltrim and rtrim are " \t\n\v\f\r" but only spaces were tested. Test that the others are trimmed as well.
* [VFS] Extend virtual working directory testJonas Devlieghere2019-12-111-0/+25
| | | | | Extend the virtual working directory test with a few edge cases that are not currently tested.
* [Loop] Add isRotated method to Loop class.Kit Barton2019-12-111-0/+55
| | | | | | | | | | | | | | | | | | Summary: This patch adds a method to determine if a loop is in rotated form (the latch is an exiting block). It also modifies the getLoopGuardBranch method to use this new method. This method can also be used in Loopfusion. Once this patch lands I will make the corresponding changes there. Reviewers: jdoerfert, Meinersbur, dmgreen, etiotto, Whitney, fhahn, hfinkel Reviewed By: Meinersbur Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65958
* [DebugInfo] Fix printing of DW_LNS_set_isaJames Henderson2019-12-111-0/+52
| | | | | | | | | | | | | | | | | The Isa register is a uint8_t, but at least on Windows this is internally an unsigned char, which meant that prior to this patch it got formatted as an ASCII character, rather than a decimal number. This patch fixes this by casting it to a uint64_t before printing. I did it this way instead of using a uint8_t formatter because a) it is simpler, and b) it allows us to change the internal type of Isa in the future without this code breaking. I also took the opportunity to test the printing of the other standard opcodes. Reviewed by: probinson Differential Revision: https://reviews.llvm.org/D71274
* [IR] allow undefined elements when checking for splat constantsSanjay Patel2019-12-101-0/+40
| | | | | This mimics the related call in SDAG. The caller is responsible for ensuring that undef values are propagated safely.
* [VectorUtils] Introduce the Vector Function Database (VFDatabase).Francesco Petrogalli2019-12-101-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduced the VFDatabase, the framework proposed in http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html. [*] In this patch the VFDatabase is used to bridge the TargetLibraryInfo (TLI) calls that were previously used to query for the availability of vector counterparts of scalar functions. The VFISAKind field `ISA` of VFShape have been moved into into VFInfo, under the assumption that different vector ISAs may provide the same vector signature. At the moment, the vectorizer accepts any of the available ISAs as long as the signature provided by the VFDatabase matches the one expected in the vectorization process. For example, when targeting AVX or AVX2, which both have 256-bit registers, the IR signature of the two vector functions associated to the two ISAs is the same. The `getVectorizedFunction` method at the moment returns the first available match. We will need to add more heuristics to the search system to decide which of the available version (TLI, AVX, AVX2, ...) the system should prefer, when multiple versions with the same VFShape are present. Some of the code in this patch is based on the work done by Sumedh Arani in https://reviews.llvm.org/D66025. [*] Notice that in the proposal the VFDatabase was called SVFS. The name VFDatabase is more in line with LLVM recommendations for naming classes and variables. Differential Revision: https://reviews.llvm.org/D67572
* [DebugInfo] Support to emit debugInfo for extern variablesYonghong Song2019-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extern variable usage in BPF is different from traditional pure user space application. Recent discussion in linux bpf mailing list has two use cases where debug info types are required to use extern variables: - extern types are required to have a suitable interface in libbpf (bpf loader) to provide kernel config parameters to bpf programs. https://lore.kernel.org/bpf/CAEf4BzYCNo5GeVGMhp3fhysQ=_axAf=23PtwaZs-yAyafmXC9g@mail.gmail.com/T/#t - extern types are required so kernel bpf verifier can verify program which uses external functions more precisely. This will make later link with actual external function no need to reverify. https://lore.kernel.org/bpf/87eez4odqp.fsf@toke.dk/T/#m8d5c3e87ffe7f2764e02d722cb0d8cbc136880ed This patch added clang support to emit debuginfo for extern variables with a TargetInfo hook to enable it. The debuginfo for the extern variable is emitted only if that extern variable is referenced in the current compilation unit. Currently, only BPF target enables to generate debug info for extern variables. The emission of such debuginfo is disabled for C++ at this moment since BPF only supports a subset of C language. Emission with C++ can be enabled later if an appropriate use case is identified. -fstandalone-debug permits us to see more debuginfo with the cost of bloated binary size. This patch did not add emission of extern variable debug info with -fstandalone-debug. This can be re-evaluated if there is a real need. Differential Revision: https://reviews.llvm.org/D70696
* Implement LWG#1203 for raw_ostream.Christian Sigg2019-12-091-2/+11
| | | | | | | | | | | | | | | | | | | Implement LWG#1203 (https://cplusplus.github.io/LWG/issue1203) for raw_ostream like libc++ does for std::basic_ostream<...>. Add a operator<< overload that takes an rvalue reference of a typed derived from raw_ostream, streams the value to it and returns the stream of the same type as the argument. This allows free operator<< to work with rvalue reference raw_ostreams: raw_ostream& operator<<(raw_ostream&, const SomeType& Value); raw_os_ostream(std::cout) << SomeType(); It also allows using the derived type like: auto Foo = (raw_string_ostream(buffer) << "foo").str(); Author: Christian Sigg <csigg@google.com> Differential Revision: https://reviews.llvm.org/D70686
* [llvm][VFABI] Add more testing for LLVM internal mangling.Francesco Petrogalli2019-12-091-0/+39
| | | | | | | | | | | | | | | | | Summary: The tests cover the internal mangling for: 1. Masked signatures. 2. Scalable signatures. 3. Masked scalable signatures with linear. Reviewers: andwar Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71146
* [CommandLine] Add missing CallbacksDavid Green2019-12-091-0/+8
| | | | | | | | | | It appears that the cl::bits options are not used anywhere in-tree. In the recent addition to add Callback's to the options, the Callback was missing from this one. This fixes it by adding the same code from the other classes. It also adds a simple test, of sorts, just to make sure these continue compiling.
* [SimplifyCFG] Handle AssumptionCache being null.Rodrigo Caetano Rocha2019-12-071-0/+50
| | | | | | | | | | | | AssumptionCache can be null in SimplifyCFGOptions. However, FoldCondBranchOnPHI() was not properly handling that when passing a null AssumptionCache to simplifyCFG. Patch by Rodrigo Caetano Rocha <rcor.cs@gmail.com> Reviewers: fhahn, lebedev.ri, spatel Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D69963
* [VPlan] Rename VPlanHCFGTransforms to VPlanTransforms (NFC).Florian Hahn2019-12-072-6/+5
| | | | | | | | | | | | The file is intended to gather various VPlan transformations, not only CFG related transforms. Actually, the only transformation there is not CFG related. Reviewers: Ayal, gilr, hsaito, rengolin Reviewed By: gilr Differential Revision: https://reviews.llvm.org/D70732
* [CommandLine] Add callbacks to OptionsDon Hinton2019-12-061-2/+64
| | | | | | | | | | | | | | | | | | | | | | Summary: Add a new cl::callback attribute to Option. This attribute specifies a callback function that is called when an option is seen, and can be used to set other options, as in option A implies option B. If the option is a `cl::list`, and `cl::CommaSeparated` is also specified, the callback will fire once for each value. This could be used to validate combinations or selectively set other options. Reviewers: beanz, thomasfinch, MaskRay, thopre, serge-sans-paille Reviewed By: beanz Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70620
* [ARM][MVE] Fix copy-paste error in VQSHL instruction ids.Simon Tatham2019-12-061-6/+6
| | | | | | | | | | | | | | | | | | | | Summary: The immediate forms of the MVE VQSHL instruction have MC names like `MVE_VSLIimms8` and `MVE_VSLIimmu32`. Those names are confusing, because VSLI is a completely different shift instruction with no semantic relation to VQSHL. But it just happens to be defined immediately before VQSHL in `ARMInstrMVE.td`, so this looks like a copy-paste error. Renamed the ids to match the instruction name. Reviewers: ostannard, dmgreen, MarkMurrayARM, miyuki Reviewed By: miyuki Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71114
* [LV] Record GEP widening decisions in recipe (NFCI)Gil Rapaport2019-12-061-5/+5
| | | | | | | | | | | | | InnerLoopVectorizer's code called during VPlan execution still relies on original IR's def-use relations to decide which vector code to generate, limiting VPlan transformations ability to modify def-use relations and still have ILV generate the vector code. This commit moves GEP operand queries controlling how GEPs are widened to a dedicated recipe and extracts GEP widening code to its own ILV method taking those recorded decisions as arguments. This reduces ingredient def-use usage by ILV as a step towards full VPlan-based def-use relations. Differential revision: https://reviews.llvm.org/D69067
* Add lookup functions for efficient lookups of addresses when using ↵Greg Clayton2019-12-051-0/+99
| | | | | | | | | | | | | | | | | GsymReader classes. Summary: Lookup functions are designed to not fully decode a FunctionInfo, LineTable or InlineInfo, they decode only what is needed into a LookupResult object. This allows lookups to avoid costly memory allocations and avoid parsing large amounts of information one a suitable match is found. LookupResult objects contain the address that was looked up, the concrete function address range, the name of the concrete function, and a list of source locations. One for each inline function, and one for the concrete function. This allows one address to turn into multiple frames and improves the signal you get when symbolicating addresses in GSYM files. Reviewers: labath, aprantl Subscribers: mgorny, hiraditya, llvm-commits, lldb-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70993
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-051-1/+4
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* [fix][unittests][llvm] Fix running unit tests without assertions. [NFCI]Francesco Petrogalli2019-12-051-0/+2
|
* [VectorUtils] API for VFShape, update VFInfo.Francesco Petrogalli2019-12-042-1/+217
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces an API to build and modify vector shapes. The validity of a VFShape can be checked with the `hasValidParameterList` method, which is also run in an assertion each time a VFShape is modified. The field VFISAKind has been moved to VFInfo under the assumption that different ISAs can map to the same VFShape (as it can be in the case of vector extensions with the same registers size, for example AVX and AVX2). Reviewers: sdesmalen, jdoerfert, simoll, hsaito Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70513
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-041-4/+1
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-041-1/+4
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* Revert "[Coverage] Revise format to reduce binary size"Vedant Kumar2019-12-041-25/+0
| | | | | | | | | | This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc. On Windows, there is an error: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data
* [Coverage] Revise format to reduce binary sizeVedant Kumar2019-12-041-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
OpenPOWER on IntegriCloud