summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [clang-format] BeforeHash added to IndentPPDirectivesPaul Hoad2019-03-208-29/+157
| | | | | | | | | | | | | | | | | | Summary: The option BeforeHash added to IndentPPDirectives. Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019 Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay Reviewed By: klimek, MyDeveloperDay Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits Patch by to-mix. Differential Revision: https://reviews.llvm.org/D52150 llvm-svn: 356613
* Introduce DWARFContext.Zachary Turner2019-03-208-54/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM's DWARF parsing library has a class called DWARFContext which holds all of the various DWARF data sections and lots of other information. LLDB's on the other hand stores all of this directly in SymbolFileDWARF / SymbolFileDWARFDwo and passes this interface around through the parsing library. Obviously this is incompatible with a world where the low level interface does not depend on the high level interface, so we need to move towards a model similar to LLVM's - i.e. all of the context needed for low level parsing should be in a single class, and that class gets passed around. This patch is a small incremental step towards achieving this. The interface and internals deviate from LLVM's for technical reasons, but the high level idea is the same. The goal is, eventually, to remove all occurrences of SymbolFileDWARF from the low level parsing code. For now I've chosen a very simple section - the .debug_aranges section to move into DWARFContext while leaving everything else unchanged. In the short term this is a bit confusing because now the information you need might come from either of 2 different locations. But it's a huge refactor to do this all at once and runs a much higher risk of breaking things. So I think it would be wise to do this in very small pieces. TL;DR - No functional change Differential Revision: https://reviews.llvm.org/D59562 llvm-svn: 356612
* AMDGPU: Don't look for constant in insert/extract_vector_elt regbankselectMatt Arsenault2019-03-203-119/+153
| | | | | | | | | The constantness shouldn't change the register bank choice. We also don't need to restrict this to only indexing VGPRs, since it's possible to index SGPRs (but SelectionDAG made using this difficult). Allow directly indexing SGPRs when appropriate. llvm-svn: 356611
* [WebAssembly] Target features sectionThomas Lively2019-03-2033-10/+611
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements a new target features section in assembly and object files that records what features are used, required, and disallowed in WebAssembly objects. The linker uses this information to ensure that all objects participating in a link are feature-compatible and records the set of used features in the output binary for use by optimizers and other tools later in the toolchain. The "atomics" feature is always required or disallowed to prevent linking code with stripped atomics into multithreaded binaries. Other features are marked used if they are enabled globally or on any function in a module. Future CLs will add linker flags for ignoring feature compatibility checks and for specifying the set of allowed features, implement using the presence of the "atomics" feature to control the type of memory and segments in the linked binary, and add front-end flags for relaxing the linkage policy for atomics. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, mgrang, jfb, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59173 llvm-svn: 356610
* [X86] Add __crc32b/__crc32w/__crc32d/__crc32q intrinsics to match gcc and icc.Craig Topper2019-03-202-0/+116
| | | | | | | | | gcc has these intrinsics in ia32intrin.h as well. And icc implements them though they aren't documented in the Intel Intrinsics Guide. Differential Revision: https://reviews.llvm.org/D59533 llvm-svn: 356609
* [AMDGPU] Fix clamp bit DAG operandMichael Liao2019-03-202-5/+30
| | | | | | | | | | | | | | | | | | Summary: - Should use `targetconstant` instead of `constant` operand for clamp bit, which is expected as an immediate operand. Under certain conditions, such as a common `i1 false` constant is used in other place and selected before the instruction with clamp bit, register operand may be added instead of immediate one. Use `targetcosntant` to enforce that. Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59608 llvm-svn: 356608
* [OPENMP]Improve detection of omp_allocator_handle_t type and predefinedAlexey Bataev2019-03-207-37/+148
| | | | | | | | | | | allocators. It is better to deduce omp_allocator_handle_t type from the predefined allocators, because omp.h header might not define it explicitly. Plus, it allows to identify the predefined allocators correctly when trying to build the allcoator for the global variables. llvm-svn: 356607
* [ARC] Add ARCOptAddrMode pass to generate postincrement loads/stores.Pete Couperus2019-03-206-2/+582
| | | | | | | | | | Build on newly introduced ARC postincrement loads/stores from r356200. Patch By Denis Antrushin! <denis@synopsys.com> Differential Revision: https://reviews.llvm.org/D59409 llvm-svn: 356606
* Fix implicit ios -> watchOS availability version mapping forAlex Lorenz2019-03-202-0/+7
| | | | | | | | versions that have the major number only rdar://48018651 llvm-svn: 356605
* [AArch64] Fix formatting (NFC)Evandro Menezes2019-03-201-21/+22
| | | | | | Indent macro instances properly. llvm-svn: 356604
* AMDHSA: Fix COMPUTE_PGM_RSRC2.USER_SGPR calculation when parsing ISA assemblyKonstantin Zhuravlyov2019-03-202-8/+8
| | | | | | | | It must match https://llvm.org/docs/AMDGPUUsage.html#initial-kernel-execution-state Differential Revision: https://reviews.llvm.org/D59570 llvm-svn: 356603
* Mark <charconv> tests as unsupported for C++11 and C++14 if you're not ↵Marshall Clow2019-03-204-0/+8
| | | | | | testing libc++. Thanks to Louis for the suggestion. llvm-svn: 356602
* [ARM] Eliminate redundant "mov rN, sp" instructions in Thumb1.Eli Friedman2019-03-206-46/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This takes sequences like "mov r4, sp; str r0, [r4]", and optimizes them to something like "str r0, [sp]". For regular stack variables, this optimization was already implemented: we lower loads and stores using frame indexes, which are expanded later. However, when constructing a call frame for a call with more than four arguments, the existing optimization doesn't apply. We need to use stores which are actually relative to the current value of sp, and don't have an associated frame index. This patch adds a special case to handle that construct. At the DAG level, this is an ISD::STORE where the address is a CopyFromReg from SP (plus a small constant offset). This applies only to Thumb1: in Thumb2 or ARM mode, a regular store instruction can access SP directly, so the COPY gets eliminated by existing code. The change to ARMDAGToDAGISel::SelectThumbAddrModeSP is a related cleanup: we shouldn't pretend that it can select anything other than frame indexes. Differential Revision: https://reviews.llvm.org/D59568 llvm-svn: 356601
* Add a __has_extension check for '#pragma clang attribute' as an ↵Erik Pilkington2019-03-202-0/+5
| | | | | | | | external-declaration This was added in r356075. llvm-svn: 356600
* [Sema] Deduplicate some availability checking logicErik Pilkington2019-03-2012-141/+111
| | | | | | | | | | | | | | | Before this commit, we emit unavailable errors for calls to functions during overload resolution, and for references to all other declarations in DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as the DiagnoseAvailabilityOfDecl based checks, as they error on the code from PR40991. This commit fixes this by removing the early checking. llvm.org/PR40991 rdar://48564179 Differential revision: https://reviews.llvm.org/D59394 llvm-svn: 356599
* Recommit "Support attribute used in member funcs of class templates"Rafael Auler2019-03-202-0/+33
| | | | | | | | | | | | | | | | | | | | This diff previously exposed a bug in LLVM's IRLinker, breaking buildbots that tried to self-host LLVM with monolithic LTO. The bug is now in LLVM by D59552 Original commit message: As PR17480 describes, clang does not support the used attribute for member functions of class templates. This means that if the member function is not used, its definition is never instantiated. This patch changes clang to emit the definition if it has the used attribute. Test Plan: Added a testcase Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D56928 llvm-svn: 356598
* [Linker] Fix crash handling appending linkageRafael Auler2019-03-203-5/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When linking two llvm.used arrays, if the resulting merged array ends up with duplicated elements (with the same name) but with different types, the IRLinker was crashing. This was supposed to be legal, as the IRLinker bitcasts elements to match types in these situations. This bug was exposed by D56928 in clang to support attribute used in member functions of class templates. Crash happened when self-hosting with LTO. Since LLVM depends on attribute used to generate code for the dump() method, ubiquitous in the code base, many input bc had a definition of this method referenced in their llvm.used array. Some of these classes got optimized, changing the type of the first parameter (this) in the dump method, leading to a scenario with a pool of valid definitions but some with a different type, triggering this bug. This is a memory bug: ValueMapper depends on (calls) the materializer provided by IRLinker, and this materializer was freely calling RAUW methods whenever a global definition was updated in the temporary merged output file. However, replaceAllUsesWith may or may not destroy constants that use this global. If the linked definition has a type mismatch regarding the new def and the old def, the materializer would bitcast the old type to the new type and the elements of the llvm.used array, which already uses bitcast to i8*, would end up with elements cascading two bitcasts. RAUW would then indirectly call the constantfolder to update the constant to the new ref, which would, instead of updating the constant, destroy it to be able to create a new constant that folds the two bitcasts into one. The problem is that ValueMapper works with pointers to the same constants that may be getting destroyed by RAUW. Obviously, RAUW can update references in the Module to do not use the old destroyed constant, but it can't update ValueMapper's internal pointers to these constants, which are now invalid. The approach here is to move the task of RAUWing old definitions outside of the materializer. Test Plan: Added LIT test case, tested clang self-hosting with D56928 and verified it works Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D59552 llvm-svn: 356597
* [NFC] Fix brace indentation.Alina Sbirlea2019-03-201-1/+1
| | | | llvm-svn: 356596
* [libc++] Use the compiler that CMake found when running lit for ↵Louis Dionne2019-03-201-1/+0
| | | | | | back-deployment tests llvm-svn: 356595
* Resubmit r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"Robert Lougher2019-03-204-0/+31
| | | | | | Failing LLD tests have been fixed in r356593. llvm-svn: 356594
* [TailCallElim] Update tests for LTO pipeline changeRobert Lougher2019-03-203-19/+8
| | | | | | | | | D58391 changed the LTO pipelines to add the tailcall elimination pass. This caused three LLD tests to fail. Differential Revision: https://reviews.llvm.org/D59604 llvm-svn: 356593
* Remove the unused return value in ASTImporter::Imported [NFC]Raphael Isemann2019-03-204-7/+4
| | | | | | | | | | | | | | | | | | Summary: `ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else) nor is it documented. Reviewers: balazske, martong, a.sidorin, shafik Reviewed By: balazske, martong Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59595 llvm-svn: 356592
* [AMDGPU] Added MsgPack format PAL metadataTim Renouf2019-03-2015-56/+860
| | | | | | | | | | | | | | Summary: PAL metadata now supports both the old linear reg=val pairs format and the new MsgPack format. The MsgPack format uses YAML as its textual representation. On output to YAML, a mnemonic name is provided for some hardware registers. Differential Revision: https://reviews.llvm.org/D57028 Change-Id: I2bbaabaaca4b3574f7e03b80fbef7c7a69d06a94 llvm-svn: 356591
* Simplify operands of masked stores and scatters based on demanded elementsPhilip Reames2019-03-203-13/+55
| | | | | | | | If we know we're not storing a lane, we don't need to compute the lane. This could be improved by using the undef element result to further prune the mask, but I want to separate that into its own change since it's relatively likely to expose other problems. Differential Revision: https://reviews.llvm.org/D57247 llvm-svn: 356590
* [clang-tidy] Fix redundant check breaking the test on many platforms.Zinovy Nis2019-03-201-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D57662 llvm-svn: 356589
* [LICM & MemorySSA] Don't sink/hoist stores in the presence of ordered loads.Alina Sbirlea2019-03-202-27/+31
| | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, if any Use existed in the loop, with a defining access in the loop, we conservatively decide to not move the store. What this approach was missing, is that ordered loads are not Uses, they're Defs in MemorySSA. So, even when the clobbering walker does not find that volatile load to interfere, we still cannot hoist a store past a volatile load. Resolves PR41140. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59564 llvm-svn: 356588
* [libc++][CMake] Clean up some of the libc++ re-exporting logicLouis Dionne2019-03-208-28/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This change allows specifying the version of libc++abi's ABI to re-export when configuring CMake. It also clearly identifies which ABI version of libc++abi each export file contains. Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS, since that knowledge is not relevant anymore. Indeed, libc++ can't be built with the toolchain that came with the 10.9 SDK anyway because the version of Clang it includes is too old (for example if you want to build a working libc++.dylib, you need bugfixes to visibility attributes that are only in recent Clangs). Reviewers: dexonsmith, EricWF Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits Differential Revision: https://reviews.llvm.org/D59489 llvm-svn: 356587
* [ValueTracking] Compute range for abs without nswNikita Popov2019-03-202-12/+9
| | | | | | | | | | | | | This is a small followup to D59511. The code that was moved into computeConstantRange() there is a bit overly conversative: If the abs is not nsw, it does not compute any range. However, abs without nsw still has a well-defined contiguous unsigned range from 0 to SIGNED_MIN. This is a lot less useful than the usual 0 to SIGNED_MAX range, but if we're already here we might as well specify it... Differential Revision: https://reviews.llvm.org/D59563 llvm-svn: 356586
* Make to_chars/from_chars work back to C++11. This means that we can use them ↵Marshall Clow2019-03-206-27/+28
| | | | | | to implement to_string as well. Reviewed as https://reviews.llvm.org/D59598. llvm-svn: 356585
* [InstCombine] Fold add nuw + uadd.with.overflowNikita Popov2019-03-202-18/+17
| | | | | | | | | | | | | Fold add nuw and uadd.with.overflow with constants if the addition does not overflow. Part of https://bugs.llvm.org/show_bug.cgi?id=38146. Patch by Dan Robertson. Differential Revision: https://reviews.llvm.org/D59471 llvm-svn: 356584
* [Remarks] Fix mismatched delete due to missing virtual destructorJordan Rupprecht2019-03-201-0/+4
| | | | | | This fixes an asan failure introduced in r356519. llvm-svn: 356583
* [AMDGPU] Factored PAL metadata handling out into its own classTim Renouf2019-03-2012-161/+360
| | | | | | | | | | | | | | | | | | | | | | Summary: This commit introduces a new AMDGPUPALMetadata class that: * is inside the AMDGPU target; * keeps an in-memory representation of PAL metadata; * provides a method to read the frontend-supplied metadata from LLVM IR; * provides methods for the asm printer to set metadata items; * provides methods to write the metadata as a binary blob to put in a .note record or as an asm directive; * provides a method to read the metadata as a binary blob from a .note record. Because llvm-readobj cannot call directly into a target, I had to remove llvm-readobj's ability to dump PAL metadata, pending a resolution to https://reviews.llvm.org/D52821 Differential Revision: https://reviews.llvm.org/D57027 Change-Id: I756dc830894fcb6850324cdcfa87c0120eb2cf64 llvm-svn: 356582
* Make __cpu_model a hidden symbol, to match libgcc.Sterling Augustine2019-03-201-0/+10
| | | | | | | | | | | | | | | Also hide __cpu_inicator_init and __cpu_features2 for similar reasons. Summary: Make __cpu_model a hidden symbol, to match libgcc. Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59561 llvm-svn: 356581
* [X86] Remove getCPUKindCanonicalName which is unused.Craig Topper2019-03-202-14/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D59578 llvm-svn: 356580
* Remove HAVE_REALPATH from config.hNico Weber2019-03-203-6/+0
| | | | | | | | | Its last use was removed in r352916. No behavior change. Differential Revision: https://reviews.llvm.org/D59601 llvm-svn: 356579
* [NFC][ASTMatchers] Alphabetically sort REGISTER_MATCHER() macros in ↵Roman Lebedev2019-03-201-16/+17
| | | | | | | | RegistryMaps::RegistryMaps() As noted in https://reviews.llvm.org/D59453#inline-526253 llvm-svn: 356578
* [AST] Disable ast-dump-openmp-parallel-master-XFAIL.c testRoman Lebedev2019-03-201-0/+3
| | | | | | | | Fails on MSVC buildbot (but not locally). Not important as it is 'testing' something that isn't supported yet anyway: https://bugs.llvm.org/show_bug.cgi?id=41022 llvm-svn: 356577
* [AMDGPU][MC] Corrected checks for DS offset0 rangeDmitry Preobrazhensky2019-03-202-1/+13
| | | | | | | | | | See bug 40889: https://bugs.llvm.org/show_bug.cgi?id=40889 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D59313 llvm-svn: 356576
* [clang-format] structured binding in range for detected as Objective CPaul Hoad2019-03-202-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++ Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160 $ clang-format.exe test.h Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format --- test.h -- ``` std::vector<std::pair<std::string,std::string>> C; void foo() { for (auto && [A,B] : C) { std::string D = A + B; } } ``` The following code fixes this issue of incorrect detection Reviewers: djasper, klimek, JonasToth, reuk Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59546 llvm-svn: 356575
* [NFC] Fix a couple of typos in libc++'s __configLouis Dionne2019-03-201-4/+4
| | | | llvm-svn: 356574
* Fix UUID decoding from minidump filesGreg Clayton2019-03-208-12/+156
| | | | | | | | | | | | | This patch fixes: UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files. UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules. UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes. Added tests for PDB70 and ELF build ID based CvRecords. Differential Revision: https://reviews.llvm.org/D59433 llvm-svn: 356573
* [CGP] fix formatting; NFCSanjay Patel2019-03-201-3/+4
| | | | llvm-svn: 356572
* [OpenCL] Generate 'unroll.enable' metadata for ↵Andrew Savonichev2019-03-202-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __attribute__((opencl_unroll_hint)) Summary: [OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint)) For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller will try to fully unroll a loop unless the trip count is not known at compile time. In that case for '.full' metadata no unrolling will be processed, while for '.enable' the loop will be partially unrolled with a heuristically chosen unroll factor. See: docs/LanguageExtensions.rst From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html __attribute__((opencl_unroll_hint)) for (int i=0; i<2; i++) { ... } In the example above, the compiler will determine how much to unroll the loop. Before the patch for __attribute__((opencl_unroll_hint)) was generated metadata !{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how much to unroll the loop. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: zzheng, dmgreen, jdoerfert, cfe-commits, asavonic, AlexeySotkin Tags: #clang Differential Revision: https://reviews.llvm.org/D59493 llvm-svn: 356571
* [clang][OpeMP] Model OpenMP structured-block in AST (PR40563)Roman Lebedev2019-03-2063-515/+1179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3: ``` structured block For C/C++, an executable statement, possibly compound, with a single entry at the top and a single exit at the bottom, or an OpenMP construct. COMMENT: See Section 2.1 on page 38 for restrictions on structured blocks. ``` ``` 2.1 Directive Format Some executable directives include a structured block. A structured block: • may contain infinite loops where the point of exit is never reached; • may halt due to an IEEE exception; • may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a _Noreturn specifier (in C) or a noreturn attribute (in C/C++); • may be an expression statement, iteration statement, selection statement, or try block, provided that the corresponding compound statement obtained by enclosing it in { and } would be a structured block; and Restrictions Restrictions to structured blocks are as follows: • Entry to a structured block must not be the result of a branch. • The point of exit cannot be a branch out of the structured block. C / C++ • The point of entry to a structured block must not be a call to setjmp(). • longjmp() and throw() must not violate the entry/exit criteria. ``` Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`, in the same sense as with the normal `noexcept` functions in C++. I.e. if throw happens, and it attempts to travel out of the `noexcept` function (here: out of the current structured-block), then the program terminates. Now, one of course can say that since it is explicitly prohibited by the Specification, then any and all programs that violate this Specification contain undefined behavior, and are unspecified, and thus no one should care about them. Just don't write broken code /s But i'm not sure this is a reasonable approach. I have personally had oss-fuzz issues of this origin - exception thrown inside of an OpenMP structured-block that is not caught, thus causing program termination. This issue isn't all that hard to catch, it's not any particularly different from diagnosing the same situation with the normal `noexcept` function. Now, clang static analyzer does not presently model exceptions. But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check, and it is even refactored as a `ExceptionAnalyzer` class for reuse. So it would be trivial to use that analyzer to check for exceptions escaping out of OpenMP structured blocks. (D59466) All that sounds too great to be true. Indeed, there is a caveat. Presently, it's practically impossible to do. To check a OpenMP structured block you need to somehow 'get' the OpenMP structured block, and you can't because it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation. Now, it is of course possible to write e.g. some AST matcher that would e.g. match every OpenMP executable directive, and then return the whatever `Stmt` is the structured block of said executable directive, if any. But i said //practically//. This isn't practical for the following reasons: 1. This **will** bitrot. That matcher will need to be kept up-to-date, and refreshed with every new OpenMP spec version. 2. Every single piece of code that would want that knowledge would need to have such matcher. Well, okay, if it is an AST matcher, it could be shared. But then you still have `RecursiveASTVisitor` and friends. `2 > 1`, so now you have code duplication. So it would be reasonable (and is fully within clang AST spirit) to not force every single consumer to do that work, but instead store that knowledge in the correct, and appropriate place - AST, class structure. Now, there is another hoop we need to get through. It isn't fully obvious //how// to model this. The best solution would of course be to simply add a `OMPStructuredBlock` transparent node. It would be optimal, it would give us two properties: * Given this `OMPExecutableDirective`, what's it OpenMP structured block? * It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`) But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`. (even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween). So i'm not sure whether or not we could re-create AST statements after they were already created? There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12 ``` 1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity. 2. You will need to support serialization/deserialization. 3. You will need to support template instantiation. 4. You will need to support codegen and take this new construct to account in each OpenMP directive. ``` Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts. Part 1: * Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class, that will tell whether this directive is stand-alone or not, as per the spec. We need it because we can't just check for the existance of associated statements, see code comment. * Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself, that assert that this is not a stand-alone directive, and either return the correct loop body if this is a loop-like directive, or the captured statement. This way, given an `OMPExecutableDirective`, we can get it's structured block. Also, since the knowledge is ingrained into the clang OpenMP implementation, it will not cause any duplication, and //hopefully// won't bitrot. Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach. Thus, there is a second part needed: * How can we check whether a given `Stmt*` is `OMPStructuredBlock`? Well, we can't really, in general. I can see this workaround: ``` class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> { using Base = RecursiveASTVisitor<FunctionASTVisitor>; public: bool VisitOMPExecDir(OMPExecDir *D) { OmpStructuredStmts.emplace_back(D.getStructuredStmt()); } bool VisitSOMETHINGELSE(???) { if(InOmpStructuredStmt) HI! } bool TraverseStmt(Stmt *Node) { if (!Node) return Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) ++InOmpStructuredStmt; Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) { OmpStructuredStmts.pop_back(); --InOmpStructuredStmt; } return true; } std::vector<Stmt*> OmpStructuredStmts; int InOmpStructuredStmt = 0; }; ``` But i really don't see using it in practice. It's just too intrusive; and again, requires knowledge duplication. .. but no. The solution lies right on the ground. Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself? This does not appear to have any impact on the memory footprint of the clang AST, since it's just a single extra bit in the bitfield. At least the static assertions don't fail. Thus, indeed, we can achieve both of the properties without a new AST node. We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`, by just calling the `getStructuredBlock()` that we just added. Test coverage that demonstrates all this has been added. This isn't as great with serialization though. Most of it does not use abbrevs, so we do end up paying the full price (4 bytes?) instead of a single bit. That price, of course, can be reclaimed by using abbrevs. In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly. I'm not seeing a third solution. If there is one, it would be interesting to hear about it. ("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.) Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]]. Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr Reviewed By: ABataev, gribozavr Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D59214 llvm-svn: 356570
* [NFC][clang][astdump] Some baseline tests for OpenMPRoman Lebedev2019-03-2048-0/+18501
| | | | | | | | | | Summary: Split off from D59214. Not a fully exhaustive test coverage, but better than what there currently is. Differential Revision: https://reviews.llvm.org/D59306 llvm-svn: 356569
* Fix sanitizer failures for 356550.Clement Courbet2019-03-201-3/+3
| | | | | | | Mark bcmp as having optimized codegen, so that asan can detect it and mark users as nobuiltin. llvm-svn: 356568
* gn build: Add build files for some clang-tools-extraNico Weber2019-03-2011-2/+155
| | | | | | | | | Adds clang-change-namespace, clang-move, clang-query, clang-reorder-fields. Differential Revision: https://reviews.llvm.org/D59554 llvm-svn: 356567
* [CGP] convert chain of 'if' to 'switch'; NFCSanjay Patel2019-03-201-14/+13
| | | | | | | | This should be extended, but CGP does some strange things, so I'm intentionally not changing the potential order of any transforms yet. llvm-svn: 356566
* Reland r356547 after fixing the tests for Linux.Zinovy Nis2019-03-201-26/+144
| | | | | | | | | | | | | [clang-tidy] Parallelize clang-tidy-diff.py This patch has 2 rationales: - large patches lead to long command lines and often cause max command line length restrictions imposed by OS; - clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy. Differential Revision: https://reviews.llvm.org/D57662 llvm-svn: 356565
* [ASTImporter] Remove obsolete function ImportTemplateParameterList.Balazs Keri2019-03-201-49/+7
| | | | | | | | | | | | | | | | | | | Summary: The ASTNodeImporter::ImportTemplateParameterList is replaced by a template specialization of 'import' that already exists and does (almost) the same thing. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59134 llvm-svn: 356564
OpenPOWER on IntegriCloud