- Apr 14, 2019
-
-
Nikita Popov authored
As motivated in D60598, this drops support for specifying both NUW and NSW in makeGuaranteedNoWrapRegion(). None of the users of this function currently make use of this. When both NUW and NSW are specified, the exact nowrap region has two disjoint parts and makeGNWR() returns one of them. This result doesn't seem to be useful for anything, but makes the semantics of the function fuzzier. Differential Revision: https://reviews.llvm.org/D60632 llvm-svn: 358340
-
Nikita Popov authored
As pointed out in D60518 folding mulo(%x, undef) to {undef, undef} isn't correct. As a correct version of this already exists in InstructionSimplify (https://github.com/llvm-mirror/llvm/blob/bd8056ef326e075cc500f3f0cfcd1193bc200594/lib/Analysis/InstructionSimplify.cpp#L4750-L4757) this is just dead code though. Drop it together with the mul(%x, 0) -> {0, false} fold that is also already handled by InstSimplify. Differential Revision: https://reviews.llvm.org/D60649 llvm-svn: 358339 -
Craig Topper authored
We know all our values are limited to 64 bits here so we don't need an APInt. This should save some generated code checking between large and small size. llvm-svn: 358338
-
Don Hinton authored
Summary: Add DefaultOption flag to CommandLineParser which provides a default option or alias, but allows users to override it for some other purpose as needed. Also, add `-h` as a default alias to `-help`, which can be seamlessly overridden by applications like llvm-objdump and llvm-readobj which use `-h` as an alias for other options. Reviewers: alexfh, klimek Reviewed By: klimek Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59746 llvm-svn: 358337
-
Heejin Ahn authored
Summary: Use member function. Reviewers: aheejin Subscribers: sunfish, hiraditya, sbc100, jgravelle-google, dschuff, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60651 Patch by Hideto Ueno (uenoku) llvm-svn: 358336
-
- Apr 13, 2019
-
-
Fangrui Song authored
llvm-svn: 358335
-
Fangrui Song authored
It is no longer used after the AliasSetTracker updating logic was removed. llvm-svn: 358334
-
Tamas Zolnai authored
llvm-svn: 358333
-
Fangrui Song authored
llvm-svn: 358332
-
Nikita Popov authored
Checked the wrong direction in the umul tests... fix predicated to line up with the test name. llvm-svn: 358331
-
Nikita Popov authored
llvm-svn: 358330
-
Michal Gorny authored
Do not use -nostdlib in target-symbols-add-unwind.test. NetBSD uses startup files to provide obligatory ELF notes in executables, and therefore using -nostdlib requires providing specially tailored input. Otherwise, kernel rejects the result as invalid executable. The replacement was suggested by Pavel Labath. Differential Revision: https://reviews.llvm.org/D60648 llvm-svn: 358329
-
Chen Zheng authored
Differential Revision: https://reviews.llvm.org/D60647 llvm-svn: 358328
-
Chen Zheng authored
llvm-svn: 358327
-
Richard Smith authored
A marker (matching /#[A-Za-z0-9_-]/) is specified by attaching a comment containing the marker to the line at which the diagnostic is expected, and then can be referenced from an expected-* directive after an @: foo // #1 // expected-error@#1 {{undeclared identifier 'foo'}} The intent is for markers to be used in situations where relative line numbers are currently used, to avoid the need to renumber when the test case is rearranged. llvm-svn: 358326 -
Philip Reames authored
This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
-
Philip Reames authored
The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324 -
Philip Reames authored
llvm-svn: 358323
-
Philip Reames authored
Motivation is to reduce silly diffs when we change the format. For instance, this causes most of D59020 to disappear. llvm-svn: 358322
-
Artem Dergachev authored
Writing stuff into an argument variable is usually equivalent to writing stuff to a local variable: it will have no effect outside of the function. There's an important exception from this rule: if the argument variable has a non-trivial destructor, the destructor would be invoked on the parent stack frame, exposing contents of the otherwise dead argument variable to the caller. If such argument is the last place where a pointer is stored before the function exits and the function is the one we've started our analysis from (i.e., we have no caller context for it), we currently diagnose a leak. This is incorrect because the destructor of the argument still has access to the pointer. The destructor may deallocate the pointer or even pass it further. Treat writes into such argument regions as "escapes" instead, suppressing spurious memory leak reports but not messing with dead symbol removal. Differential Revision: https://reviews.llvm.org/D60112 llvm-svn: 358321
-
Kostya Serebryany authored
[libFuzzer] speedup the merge step in the fork mode by merging only the files that have unique features. llvm-svn: 358320
-
Philip Reames authored
The reserved uint8 field in the location block of the stackmap record is used to denote the size of the location. Patch By: jacob.hughes@kcl.ac.uk Differential Revision: https://reviews.llvm.org/D59167 llvm-svn: 358319
-
Amara Emerson authored
This enables the simple copy combine that already exists in the CombinerHelper. However, it exposed a bug in the GISelChangeObserver where it wouldn't clear a set of MIs to process, and so would end up causing a crash when deleted MIs were being added to the combiner worklist again. Differential Revision: https://reviews.llvm.org/D60579 llvm-svn: 358318
-
Kostya Serebryany authored
llvm-svn: 358317
-
Julian Lettner authored
The libdispatch tests are now not tied to Darwin anymore. Move them to their own platform-independent folder. llvm-svn: 358316
-
Thomas Lively authored
Summary: This ensures that object files will continue to validate as WebAssembly modules in the presence of bulk memory operations. Engines that don't support bulk memory operations will not recognize the DataCount section and will report validation errors, but that's ok because object files aren't supposed to be run directly anyway. Reviewers: aheejin, dschuff, sbc100 Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60623 llvm-svn: 358315
-
Amara Emerson authored
This crash was introduced in r358032 as we try to construct an EVT from an MVT in order to find the register type for the calling conv. Fall back instead of trying to do this with an invalid MVT coming from i256. llvm-svn: 358314
-
Alina Sbirlea authored
Summary: When inserting a new Def, MemorySSA may be have non-minimal number of Phis. While inserting, the walk to find the previous definition may cleanup minimal Phis. When the last definition is trivial to obtain, we do not cache it. It is possible while getting the previous definition for a Def to get two different answers: - one that was straight-forward to find when walking the first path (a trivial phi in this case), and - another that follows a cleanup of the trivial phi, it determines it may need additional Phi nodes, it inserts them and returns a new phi in the same position as the former trivial one. While the Phis added for the second path are all redundant, they are not complete (the walk is only done upwards), and they are not properly cleaned up afterwards. A way to fix this problem is to cache the straight-forward answer we got on the first walk. The caching is only kept for the duration of a getPreviousDef call, and for Phis we use TrackingVH, so removing the trivial phi will lead to replacing it with the next dominating phi in the cache. Resolves PR40749. Reviewers: george.burgess.iv Subscribers: jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60634 llvm-svn: 358313
-
Amara Emerson authored
If a shufflevector's mask vector has an element with "undef" then the generic instruction defining that element register is a G_IMPLICT_DEF instead of G_CONSTANT. This fixes the selector to handle this case, and for now assumes that undef just means zero. In future we'll optimize this case properly. llvm-svn: 358312
-
Max Moroz authored
Summary: 1. Do not create DFSan labels for the bytes which we do not trace. This is where we run out of labels at the first place. 2. When dumping the traces on the disk, make sure to offset the label identifiers by the number of the first byte in the trace range. 3. For the last label, make sure to write it at the last position of the trace bit string, as that label represents the input size, not any particular byte. Also fixed the bug with division in python which I've introduced when migrated the scripts to Python3 (`//` is required for integral division). Otherwise, the scripts are wasting too much time unsuccessfully trying to collect and process traces from the long inputs. For more context, see https://github.com/google/oss-fuzz/issues/1632#issuecomment-481761789 Reviewers: kcc Reviewed By: kcc Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D60538 llvm-svn: 358311
-
Thomas Lively authored
Summary: This brings the backend in line with Clang. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60594 llvm-svn: 358310
-
Julian Lettner authored
Now that our tests don't depend on Foundation anymore, don't link it in. llvm-svn: 358309
-
Julian Lettner authored
After this change, most tests don't have a dependency on Foundation. Note: To hold the file name `tempnam` allocates a new buffer. We leak this buffer (omit the free), but I don't think we need to care. Reviewed By: kubamracek Differential Revision: https://reviews.llvm.org/D60591 llvm-svn: 358308 -
Amy Huang authored
[MS] Add metadata for __declspec(allocator) Original summary: Emit !heapallocsite in the metadata for calls to functions marked with __declspec(allocator). Eventually this will be emitted as S_HEAPALLOCSITE debug info in codeview. Differential Revision: https://reviews.llvm.org/D60237 llvm-svn: 358307
-
Kostya Serebryany authored
[libFuzzer] support -runs=N in the fork mode. Make sure we see one-line reports from ubsan in the fork mode. Test both llvm-svn: 358306
-
Nikita Popov authored
makeGuaranteedNoWrapRegion() is actually makeExactNoWrapRegion() as long as only one of NUW or NSW is specified. This is not obvious from the current documentation, and some code seems to think that it is only exact for single-element ranges. Clarify docs and add tests to be more confident this really holds. There are currently no users of makeGuaranteedNoWrapRegion() that pass both NUW and NSW. I think it would be best to drop support for this entirely and then rename the function to makeExactNoWrapRegion(). Knowing that the no-wrap region is exact is useful, because we can backwards-constrain values. What I have in mind in particular is that LVI should be able to constrain values on edges where the with.overflow overflow flag is false. Differential Revision: https://reviews.llvm.org/D60598 llvm-svn: 358305
-
Alina Sbirlea authored
Summary: Create a method to forget everything in SCEV. Add a cl::opt and PassManagerBuilder option to use this in LoopUnroll. Motivation: Certain Halide applications spend a very long time compiling in forgetLoop, and prefer to forget everything and rebuild SCEV from scratch. Sample difference in compile time reduction: 21.04 to 14.78 using current ToT release build. Testcase showcasing this cannot be opensourced and is fairly large. The option disabled by default, but it may be desirable to enable by default. Evidence in favor (two difference runs on different days/ToT state): File Before (s) After (s) clang-9.bc 7267.91 6639.14 llvm-as.bc 194.12 194.12 llvm-dis.bc 62.50 62.50 opt.bc 1855.85 1857.53 File Before (s) After (s) clang-9.bc 8588.70 7812.83 llvm-as.bc 196.20 194.78 llvm-dis.bc 61.55 61.97 opt.bc 1739.78 1886.26 Reviewers: sanjoy Subscribers: mehdi_amini, jlebar, zzheng, javed.absar, dmgreen, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60144 llvm-svn: 358304
-
Alina Sbirlea authored
Summary: After introducing the limit for clobber walking, `walkToPhiOrClobber` would assert that the limit is at least 1 on entry. The test included triggered that assert. The callsite in `tryOptimizePhi` making the calls to `walkToPhiOrClobber` is structured like this: ``` while (true) { if (getBlockingAccess()) { // calls walkToPhiOrClobber } for (...) { walkToPhiOrClobber(); } } ``` The cleanest fix is to check if the limit was reached inside `walkToPhiOrClobber`, and give an allowence of 1. This approach not make any alias() calls (no calls to instructionClobbersQuery), so the performance condition is enforced. The limit is set back to 0 if not used, as this provides info on the fact that we stopped before reaching a true clobber. Reviewers: george.burgess.iv Subscribers: jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60479 llvm-svn: 358303 -
Louis Dionne authored
llvm-svn: 358302
-
Nicolas Lesser authored
Not all compilers support attributes before `extern "C"`. gcc is the main one that doesn't support it. llvm-svn: 358301
-