- Mar 24, 2017
-
-
Rui Ueyama authored
The original code is a big `if` and `else` which ends with `continue` like this: if (cond) { ... // fall through } else { ... continue; } This patch rewrites it with the following. if (!cond) { ... continue; } ... llvm-svn: 298672
-
Kostya Serebryany authored
[libFuzzer] increase kFeatureSetSize to 2^21 and make InputCorpus scale to that size. This will potentially make libFuzzer more sensitive on targets with lots of signals llvm-svn: 298671
-
Dean Michael Berris authored
Summary: Now that XRay doesn't require a runtime dependency on a C++ standard library, we remove that dependency from the clang linker flags. Reviewers: saugustine, pelikan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31313 llvm-svn: 298670
-
Rui Ueyama authored
llvm-svn: 298669
-
Rui Ueyama authored
llvm-svn: 298668
-
Rui Ueyama authored
llvm-svn: 298667
-
Kostya Serebryany authored
llvm-svn: 298666
-
Adrian Prantl authored
llvm-svn: 298665
-
Adrian Prantl authored
While fixing a malformed testcase, I discovered that the code exercised by it was wrong, too. llvm-svn: 298664
-
Richard Smith authored
llvm-svn: 298663
-
Reid Kleckner authored
This prevents crashes when attempting to instrument functions containing C++ try. Sanitizer coverage will still fail at runtime when an exception is thrown through a sancov instrumented function, but that seems marginally better than what we have now. The full solution is to color the blocks in LLVM IR and only instrument blocks that have an unambiguous color, using the appropriate token. llvm-svn: 298662
-
Dehao Chen authored
Summary: For the following CFG: A->B B->C A->C If there is another edge B->D, then ABC should not be considered as triangle. Reviewers: davidxl, iteratee Reviewed By: iteratee Subscribers: nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D31310 llvm-svn: 298661
-
Dehao Chen authored
Summary: In DeadArgumentElimination, the call instructions will be replaced. We also need to set the prof weights so that function inlining can find the correct profile. Reviewers: eraman Reviewed By: eraman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31143 llvm-svn: 298660
-
Bryant Wong authored
Library functions can have specific semantics that affect the behavior of certain passes. DSE, for instance, gives special treatment to malloc-ed pointers but not to pointers returned from an equivalently typed (but differently named) function. MetaRenamer ought not to alter program semantics, so library functions must remain untouched. Reviewers: mehdi_amini, majnemer, chandlerc, davide Reviewed By: davide Subscribers: davide, llvm-commits Differential Revision: https://reviews.llvm.org/D31304 llvm-svn: 298659
-
Alex Shlyapnikov authored
Summary: Fixes test broken by D30384 Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D31312 llvm-svn: 298658
-
Richard Smith authored
llvm-svn: 298657
-
Dehao Chen authored
Summary: The current prefix based function layout algorithm only looks at function's entry count, which is not sufficient. A function should be grouped together if its entry count or any call edge count is hot. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31225 llvm-svn: 298656
-
Krzysztof Parzyszek authored
- Avoid explosive growth of the simplification queue by not queuing expressions that are alredy in it. - Add an iteration counter and abort after a sufficiently large number of iterations (assuming that it's a symptom of an infinite loop). llvm-svn: 298655
-
- Mar 23, 2017
-
-
Kostya Serebryany authored
llvm-svn: 298654
-
Petr Hosek authored
This could be used to either disable the runtimes build altogether or avoid building them but still generate the build targets. Differential Revision: https://reviews.llvm.org/D31060 llvm-svn: 298653
-
Krzysztof Parzyszek authored
This is another step towards implementing register classes with parametrized register/spill sizes. Differential Revision: https://reviews.llvm.org/D31299 llvm-svn: 298652
-
Jessica Paquette authored
Remove an unused lambda capture that made some bots unhappy. llvm-svn: 298651
-
Alex Shlyapnikov authored
Summary: This change addresses https://github.com/google/sanitizers/issues/766. I tested the change with make check-asan and the newly added test case. Reviewers: ygribov, kcc, alekseyshl Subscribers: kubamracek, llvm-commits Patch by mrigger Differential Revision: https://reviews.llvm.org/D30384 llvm-svn: 298650
-
Reid Kleckner authored
Summary: When dumping these records from an object file section, we should use only one type database. However, when dumping from a PDB, we should use two: one for the type stream and one for the IPI stream. Certain type records that normally live in the .debug$T object file section get moved over to the IPI stream of the PDB file and they get new indices. So far, I've noticed that the MSVC linker always moves these records into IPI: - LF_FUNC_ID - LF_MFUNC_ID - LF_STRING_ID - LF_SUBSTR_LIST - LF_BUILDINFO - LF_UDT_MOD_SRC_LINE These records have index fields that can point into TPI or IPI. In particular, LF_SUBSTR_LIST and LF_BUILDINFO point to LF_STRING_ID records to describe compilation command lines. I've modified the dumper to have an optional pointer to the item DB, and to do type name lookup of these fields in that DB. See printItemIndex. The result is that our pdbdump-headers.test is more faithful to the PDB contents and the output is less confusing. Reviewers: ruiu Subscribers: amccarth, zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D31309 llvm-svn: 298649
-
Jessica Paquette authored
The old candidate collection method in the outliner caused some very large regressions in compile time on large tests. For MultiSource/Benchmarks/7zip it caused a 284.07 s or 1156% increase in compile time. On average, using the SingleSource/MultiSource tests, it caused an average increase of 8 seconds in compile time (something like 1000%). This commit replaces that candidate collection method with a new one which only visits each node in the tree once. This reduces the worst compile time increase (still 7zip) to a 0.542 s overhead (22%) and the average compile time increase on SingleSource and MultiSource to 0.018 s (4%). llvm-svn: 298648
-
Dehao Chen authored
Summary: This is the test added for https://reviews.llvm.org/D31217 Reviewers: tejohnson, mehdi_amini Reviewed By: tejohnson Subscribers: cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31219 llvm-svn: 298647
-
Dehao Chen authored
Summary: loop unrolling and icp will make the sample profile annotation much harder in the backend. So disable these 2 optimization in the ThinLTO compile phase. Will add a test in cfe in a separate patch. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D31217 llvm-svn: 298646
-
Richard Smith authored
llvm-svn: 298645
-
Craig Topper authored
[InstCombine] Remove some code from visitAnd that dealt with trying to reduce the LHS of a sub to 0. This should now be fully handled by SimplifyDemandedInstructionBits now. Now that we call ShrinkDemandedConstant on the RHS of sub this should be taken care of. This code doesn't trigger on any in tree regressions, but did before ShrinkDemandedConstant was added to the RHS. llvm-svn: 298644
-
Erich Keane authored
GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to. This is the required LLVM changes to make this happen. Differential Revision: https://reviews.llvm.org/D29598 llvm-svn: 298643
-
Adrian Prantl authored
It is not guaranteed that the memory used for MachineBasicBlocks in the previous MachineFunction hasn't been freed, so holding on to a pointer to the last function's isn't correct. Particularly I have observed the sret.ll testcase failing because the first BasicBlock in the new function happened to be allocated to the exact same memory as the previously saved and (deleted) PrevInstBB. llvm-svn: 298642
-
Gil Rapaport authored
The new test asserts that scalarized memory operations get memcheck metadata added even if the loop is only unrolled. Differential Revision: https://reviews.llvm.org/D30972 llvm-svn: 298641
-
Anna Thomas authored
Using AssemblyAnnotationWriter for LVI printer prints for instructions and basic blocks. So, we explicitly need to print LVI info for the arguments of the function (these are values and not instructions). llvm-svn: 298640
-
Teresa Johnson authored
Summary: Clang companion patch to LLVM patch D31027, which adds support for emitting minimized bitcode file for use in the thin link step. Add a cc1 option -fthin-link-bitcode=<file> to trigger this behavior. Depends on D31027. Reviewers: mehdi_amini, pcc Subscribers: cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31050 llvm-svn: 298639
-
Teresa Johnson authored
Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
-
Eric Christopher authored
llvm-svn: 298637
-
Kostya Kortchinsky authored
Summary: Scudo didn't have any test using multiple threads. Add one, borrowed from lsan. Reviewers: kcc, alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31297 llvm-svn: 298636
-
Erich Keane authored
Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
-
Nirav Dave authored
Summary: Fixes pr32329. Reviewers: spatel, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31286 llvm-svn: 298633
-
Rui Ueyama authored
llvm-svn: 298632
-