summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Reland "[clang] Report sanitizer blacklist as a dependency in cc1"Jan Korous2019-11-086-21/+62
| | | | This reverts commit 9b8413ac6e56e7a6e0ba884773d13bcf9414bd43.
* DebugInfo: Use separate macinfo contributions for each CUDavid Blaikie2019-11-0811-63/+69
| | | | | | | | | | | | | | | | The macinfo support was broken for LTO situations, by terminating macinfo lists only once - multiple macinfo contributions were correctly labeled, but they all continued/flowed into later contributions until only one terminator appeared at the end of the section. Correctly terminate each contribution & fix the parsing to handle this situation too. The parsing fix is also necessary for dumping linked binaries - the previous code would stop at the end of the first contribution - missing all later contributions in a linked binary. It'd be nice to improve the dumping to print the offsets of each contribution so it'd be easier to know which CU AT_macro_info refers to which macinfo contribution.
* [clang-format] NFC allow Format.h to be clang-formatted but still maintain ↵paul_hoad2019-11-082-7/+14
| | | | | | | | | | | | | | | | | | | | | the same doc layout in ClangFormatStyleOptions.rst Summary: Format.h is used to generate ClangFormatStyleOptions.rst, the layout of the comments is critical to the rst file. Accidentally clang-formatting Format.h can lead to the .rst changing. This revision simply add // clang-format off/on statement around the areas who formatting needs to be maintained, mainly around the options that are related to what happens when the line breaks due to `ColumnLimit` (which is what is happening to the comment) This allows Format.h to be clang-formatted without causing a change in the documentation when dump_format_style.py is rerun, which is also part of the revision. Reviewers: mitchell-stellar, klimek, sammccall, owenpan Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D69951
* gn build: Merge f0af11d86f8LLVM GN Syncbot2019-11-081-0/+1
|
* [DDG] Data Dependence Graph - Pi Blockbmahjour2019-11-0811-318/+751
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG nodes that are part of a strongly-connected component of the graph. Replacing all the SCCs with pi-blocks results in an acyclic representation of the DDG. For example if we have: {a -> b}, {b -> c, d}, {c -> a} the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows: {p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a} In this implementation the edges between nodes that are part of the pi-block are preserved. The crossing edges (edges where one end of the edge is in the set of nodes belonging to an SCC and the other end is outside that set) are replaced with corresponding edges to/from the pi-block node instead. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack Tag: #llvm Differential Revision: https://reviews.llvm.org/D68827
* [AArch64][X86] Don't assume __powidf2 is available on Windows.Eli Friedman2019-11-087-64/+144
| | | | | | | | | | We had some code for this for 32-bit ARM, but this doesn't really need to be in target-specific code; generalize it. (I think this started showing up recently because we added an optimization that converts pow to powi.) Differential Revision: https://reviews.llvm.org/D69013
* Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations ↵Gil Rapaport2019-11-088-209/+131
| | | | | | (NFCI)" This reverts commit 11ed1c0239fd51fd2f064311dc7725277ed0a994 - causes an assert failure.
* [ELF] Fix stack-use-after-scope after D69592 and 69650Fangrui Song2019-11-081-2/+4
|
* Reapply [LVI] Normalize pointer behaviorNikita Popov2019-11-082-90/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix cache invalidation by not guarding the dereferenced pointer cache erasure by SeenBlocks. SeenBlocks is only populated when actually caching a value in the block, which doesn't necessarily have to happen just because dereferenced pointers were calculated. ----- Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* [clang] Add VFS support for sanitizers' blacklistsJan Korous2019-11-087-10/+69
| | | | Differential Revision: https://reviews.llvm.org/D69648
* [cmake] Remove LLVM_{BUILD,LINK}_LLVM_DYLIB options on WindowsTom Stellard2019-11-085-7/+18
| | | | | | | | | | | | | | Summary: The options aren't supported so they can be removed. Reviewers: beanz, smeenai, compnerd Reviewed By: compnerd Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69877
* Reapply "Fix crash on switch conditions of non-integer types in templates"Melanie Blower2019-11-089-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reapplies commit 76945821b9cad3. The first version broke buildbots due to clang-tidy test fails. The fails are because some errors in templates are now diagnosed earlier (does not wait till instantiation). I have modified the tests to add checks for these diagnostics/prevent these diagnostics. There are no additional code changes. Summary of code changes: Clang currently crashes for switch statements inside a template when the condition is a non-integer field member because contextual implicit conversion is skipped when parsing the condition. This conversion is however later checked in an assert when the case statement is handled. The conversion is skipped when parsing the condition because the field member is set as type-dependent based on its containing class. This patch sets the type dependency based on the field's type instead. This patch fixes Bug 40982. Reviewers: rnk, gribozavr2 Patch by: Elizabeth Andrews (eandrews) Differential revision: https://reviews.llvm.org/D69950
* [ThinLTO] Fix bug when importing writeonly variablesevgeny2019-11-085-8/+80
| | | | | | | | Patch enables import of write-only variables with non-trivial initializers to fix linker errors. Initializers of imported variables are converted to 'zeroinitializer' to avoid promotion of referenced objects. Differential revision: https://reviews.llvm.org/D70006
* [cmake] Remove SVN support from VersionFromVCS.cmakeTom Stellard2019-11-082-79/+30
| | | | | | | | | | Reviewers: phosek Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69682
* [PowerPC][compiler-rt][builtins]Fix __fixunstfti builtin on PowerPCLei Huang2019-11-082-10/+662
| | | | | | | | | | | __fixunstfti converts a long double (IBM double-double) to an unsigned 128 bit integer. This patch enables it to handle a previously unhandled case in which a negative low double may impact the result of the conversion. Collaborated with @masoud.ataei and @renenkel. Patch By: Baptiste Saleil Differential Revision: https://reviews.llvm.org/D69193
* Properly propagate is_variadic.Adrian Prantl2019-11-081-1/+1
| | | | | This fixes a copy&paste error made when adapting to new clang API which was promptly caught by the bots.
* [ELF] Suggest extern "C" when the definition is mangled while an undefined ↵Fangrui Song2019-11-082-4/+57
| | | | | | | | | | | | | | | | | | | | reference is not The definition may be mangled while an undefined reference is not. This may come up when (1) the reference is from a C file or (2) the definition misses an extern "C". (2) is more common. Suggest an arbitrary mangled name that matches the undefined reference, if such a definition exists. ld.lld: error: undefined symbol: foo >>> referenced by a.o:(.text+0x1) >>> did you mean to declare foo(int) as extern "C"? >>> defined in: a1.o Reviewed By: dblaikie, ruiu Differential Revision: https://reviews.llvm.org/D69650
* [ELF] Suggest extern "C" when an undefined reference is mangled while the ↵Fangrui Song2019-11-083-4/+43
| | | | | | | | | | | | definition is not When missing an extern "C" declaration, an undefined reference may be mangled while the definition is not. Suggest the missing extern "C" and the base name. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D69592
* [JumpThreading] Fix a comment typo (NFC)Kazu Hirata2019-11-081-1/+1
| | | | | | | | | | Reviewers: kazu Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70013
* remove redundant LLVM version from version string when setting CLANG_VENDORNick Desaulniers2019-11-081-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When downstream LLVM distributions (like AOSP) set the CLANG_VENDOR cmake variable, the version string printed by the clang driver looks like: $ clang --version [CLANG_VENDOR] clang version X.X.X ([CLANG_REPOSITORY_STRING] sha) (based on LLVM X.X.X) Rather than the more standard: $ clang --version clang version X.X.X ([CLANG_REPOSITORY_STRING] sha) Based on feedback the the version string is a little long, the trailing "(based on LLVM X.X.X)" is redundant and makes less sense after moving LLVM to the monorepo. And it is only added should vendors set the cmake variable CLANG_VENDOR. Let's remove it. Reviewers: jyknight, eli.friedman, rsmith, rjmccall, efriedma Reviewed By: efriedma Subscribers: arphaman, efriedma, cfe-commits, srhines Tags: #clang Differential Revision: https://reviews.llvm.org/D69925
* Revert "[LVI] Normalize pointer behavior"Nikita Popov2019-11-082-96/+90
| | | | | | | This reverts commit 15bc4dc9a8949f9cffd46ec647baf0818d28fb28. clang-cmake-x86_64-sde-avx512-linux buildbot reported quite a few compile-time regressions in test-suite, will investigate.
* [lldb] Make Asan/SIP workaround work for Python 3Jonas Devlieghere2019-11-081-2/+4
| | | | | Make the check generic instead of hard-coding the path to Python 2. This also fixes the print-syntax to be compatible with both versions.
* [lldb] Prevent Asan/SIP workaround from affecting Python in /usr/local/binJonas Devlieghere2019-11-081-1/+1
| | | | | | | The code that works around SIP was unintentionally being triggered for /usr/local/bin/python as well. That caused trouble on GreenDragon where we were swapping out a Python 3 executable with the system's Python 2 executable.
* Fix two typos in one test name, three days before its 10th birthday! (NFC)Adrian Prantl2019-11-081-0/+0
|
* Adapt LLDB to clang API change in ObjCMethodDecl::create().Adrian Prantl2019-11-082-15/+24
|
* [LVI] Normalize pointer behaviorNikita Popov2019-11-082-90/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* PODSmallVector - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-081-4/+4
|
* TimeTraceProfiler - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-3/+3
|
* Obj2YamlError - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-1/+1
|
* CrashRecoveryContextCleanup - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-081-4/+4
| | | | Remove default values from constructor.
* Redeclare Objective-C property accessors inside the ObjCImplDecl in which ↵Adrian Prantl2019-11-0829-197/+505
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | they are synthesized. This patch is motivated by (and factored out from) https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting with DWARF 5 all Objective-C methods are nested inside their containing type, and that patch implements this for synthesized Objective-C properties. 1. SemaObjCProperty populates a list of synthesized accessors that may need to inserted into an ObjCImplDecl. 2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all accessors for which no override was provided into their ObjCImplDecl. This patch does *not* synthesize AST function *bodies*. Moving that code from the static analyzer into Sema may be a good idea though. 3. Places that expect all methods to have bodies have been updated. I did not update the static analyzer's inliner for synthesized properties to point back to the property declaration (see test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which I believed to be more bug than a feature. Differential Revision: https://reviews.llvm.org/D68108 rdar://problem/53782400
* [LICM] Support hosting of dynamic allocas out of loopsPhilip Reames2019-11-082-0/+213
| | | | | | | | | | | | This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop). Now, I really hope no one is actually using dynamic allocas. As such, why this patch? Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction. Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages. Differential Revision: https://reviews.llvm.org/D69227
* [LICM] Hoisting of widenable conditions out of loopsPhilip Reames2019-11-083-8/+47
| | | | | | The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation. If anyone bisects a problem to this, a counter example will be very interesting. Differential Revision: https://reviews.llvm.org/D69907
* [CostModel] Fixed isExtractSubvectorMask for undef index off endTim Renouf2019-11-082-1/+6
| | | | | | | | | | | | | | | | | | | ShuffleVectorInst::isExtractSubvectorMask, introduced in [CostModel] Add SK_ExtractSubvector handling to getInstructionThroughput (PR39368) erroneously thought that %340 = shufflevector <4 x float> %339, <4 x float> undef, <3 x i32> <i32 2, i32 3, i32 undef> is a subvector extract, even though it goes off the end of the parent vector with the undef index. That then caused an assert in BasicTTIImplBase::getExtractSubvectorOverhead. This commit fixes that, by not considering the above a subvector extract. Differential Revision: https://reviews.llvm.org/D70005 Change-Id: I87b8b00b24bef19ffc9a1b82ef4eca3b8a246eaf
* [PowerPC] Remove redundant CRSET/CRUNSET in custom lowering of known CR bit ↵Yi-Hong Lyu2019-11-084-5/+42
| | | | | | | | | | | | | | | | | | | | | | spills We lower known CR bit spills (CRSET/CRUNSET) to load and spill the known value but forgot to remove the redundant spills. e.g., This sequence was used to spill a CRUNSET: crclr 4*cr5+lt mfocrf r3,4 rlwinm r3,r3,20,0,0 stw r3,132(r1) Custom lowering of known CR bit spills lower it to: crxor 4*cr5+lt, 4*cr5+lt, 4*cr5+lt li r3,0 stw r3,132(r1) crxor is redundant if there is no use of 4*cr5+lt so we should remove it Differential revision: https://reviews.llvm.org/D67722
* raw_ostream - fix static analyzer warnings. NFCI.Simon Pilgrim2019-11-082-14/+15
| | | | | - uninitialized variables - make BufferKind a scoped enum class
* YAMLTraits.h - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-1/+1
|
* libclc: Drop the old python based build systemJan Vesely2019-11-083-536/+0
| | | | | Reviewer: tstellar Differential Revision: https://reviews.llvm.org/D69966
* libclc: Drop travisJan Vesely2019-11-081-200/+0
| | | | | | | It only works for standalone repos. Reviewer: tstellar Differential Revision: https://reviews.llvm.org/D69965
* [lldb] Skip parts of TestCallOverriddenMethod.py on LinuxRaphael Isemann2019-11-081-4/+18
| | | | | | The function call and the constructor call fail now several Linux bots (Swift CI, my own bot and Stella's Debian system), so let's disable the relevant test parts until we can figure out why it is failing.
* [NFC] ConstantRange::subWithNoWrap(): fixup commentRoman Lebedev2019-11-081-1/+1
|
* [ConstantRange] Add umul_sat()/smul_sat() methodsRoman Lebedev2019-11-083-0/+57
| | | | | | | | | | | | | | | | | | | | | | | Summary: To be used in `ConstantRange::mulWithNoOverflow()`, may in future be useful for when saturating shift/mul ops are added. These are precise as far as i can tell. I initially though i will need `APInt::[us]mul_sat()` for these, but it turned out much simpler to do what `ConstantRange::multiply()` does - perform multiplication in twice the bitwidth, and then truncate. Though here we want saturating signed truncation. Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69994
* [APInt] Add saturating truncation methodsRoman Lebedev2019-11-083-0/+55
| | | | | | | | | | | | | | | | Summary: The signed one is needed for implementation of `ConstantRange::smul_sat()`, unsigned is for completeness only. Reviewers: nikic, RKSimon, spatel Reviewed By: nikic Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69993
* find_interesting_reviews.py: avoid crash on non-ascii data.Kristof Beyls2019-11-081-1/+1
|
* OutputStream - fix static analyzer warnings. NFCI.Simon Pilgrim2019-11-081-4/+4
| | | | | - uninitialized variables - make getBufferCapacity() const
* directory_entry - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-1/+1
|
* Timer - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-081-4/+4
|
* ReplacementItem - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-1/+1
|
* Hashing - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-081-2/+2
|
* [clang-format] Ensure dump_format_style.py can generate ↵paul_hoad2019-11-082-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | ClangFormatStyleOptions.rst without manual intervention Summary: This revision is the last in a series of revisions to return `clang/doc/tools/dump_format_style.py` to be being able to parse Format.h without needing to manually merge the ClangFormatStyleOptions.rst file. The final modification to dump_format_style.py is needed following the addition of a nested enumeration inside a nested structure following the introduction of {D68296} Prior related revisions will allow for a fully clang-formatted `clang/include/clang/Format/Format.h` to once again be used at the source. {D69951} {D69433} {D69404} Reviewers: mitchell-stellar, klimek, sammccall, owenpan Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D70003
OpenPOWER on IntegriCloud