summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-111-26/+0
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* [CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver ↵Fangrui Song2019-09-111-3/+24
| | | | | | | | | | | | | | linkage type Multi-versioned functions defined by cpu_dispatch and implemented with IFunc can not be called outside the translation units where they are defined due to lack of symbols. This patch add function aliases for these functions and thus make them visible outside. Differential Revision: https://reviews.llvm.org/D67058 Patch by Senran Zhang llvm-svn: 371586
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Fix for PR43175: compiler crash when trying to emit noncapturableAlexey Bataev2019-09-101-0/+5
| | | | | | | | | | | | | | constant. If the constexpr variable is partially initialized, the initializer can be emitted as the structure, not as an array, because of some early optimizations. The llvm variable gets the type from this constant and, thus, gets the type which is pointer to struct rather than pointer to an array. We need to convert this type to be truely array, otherwise it may lead to the compiler crash when trying to emit array subscript expression. llvm-svn: 371548
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-101-26/+0
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [NewPM][Sancov] Create the Sancov Pass after building the pipelinesLeonard Chan2019-09-081-17/+7
| | | | | | | | | | | | | | | | | | | | We're running into linker errors from missing sancov sections: ``` ld.lld: error: relocation refers to a discarded section: __sancov_guards >>> defined in user-arm64-ubsan-sancov-full.shlib/obj/third_party/ulib/scudo/scudo.wrappers_c.cc.o >>> referenced by common.h:26 (../../zircon/third_party/ulib/scudo/common.h:26) ... many other references ``` I believe this is due to a pass in the default pipeline that somehow discards these sections. The ModuleSanitizerCoveragePass was initially added at the start of the pipeline. This now adds it to the end of the pipeline for optimized and unoptimized builds. Differential Revision: https://reviews.llvm.org/D67323 llvm-svn: 371326
* Remove stale TLI Module level pass registrationTeresa Johnson2019-09-071-1/+0
| | | | | | | | Clang patch to adapt to LLVM changes in D66428 that make the TLI require a Function. There is no longer a module-level TargetLibraryAnalysis, so remove its registration llvm-svn: 371285
* Use musttail for variadic method thunks when possibleReid Kleckner2019-09-061-11/+41
| | | | | | | | | | | | | | | | | | | | | This avoids cloning variadic virtual methods when the target supports musttail and the return type is not covariant. I think we never implemented this previously because it doesn't handle the covariant case. But, in the MS ABI, there are some cases where vtable thunks must be emitted even when the variadic method defintion is not available, so it looks like we need to implement this. Do it for both ABIs, since it's a nice size improvement and simplification for Itanium. Emit an error when emitting thunks for variadic methods with a covariant return type. This case is essentially not implementable unless the ABI provides a way to perfectly forward variadic arguments without a tail call. Fixes PR43173. Differential Revision: https://reviews.llvm.org/D67028 llvm-svn: 371269
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): pass a vector to EmitCheck()Roman Lebedev2019-09-061-2/+6
| | | | | | | | Will be easier to add a new 'check' in a follow-up. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371208
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): refactor ↵Roman Lebedev2019-09-061-25/+52
| | | | | | | | | | | EmitGEPOffsetInBytes() helper It shouldn't really be inlined into the EmitCheckedInBoundsGEP(). Refactoring it beforehand will make follow-up changes more obvious. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371207
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): add some comments to ↵Roman Lebedev2019-09-061-8/+18
| | | | | | | | | | pointer-overflow check It's rather eye-twiching, some comments may help here.. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371206
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-2/+40
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* Revert: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and ↵Alexandre Ganea2019-09-052-14/+5
| | | | | | mark them as artificial llvm-svn: 371113
* [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them ↵Alexandre Ganea2019-09-052-5/+14
| | | | | | | | as artificial Differential Revision: https://reviews.llvm.org/D66328 llvm-svn: 371080
* Add -m(no)-spe to clangJustin Hibbits2019-09-051-1/+2
| | | | | | | | | | | | | | Summary: r337347 added support for the Signal Processing Engine (SPE) to LLVM. This follows that up with the clang side. This adds -mspe and -mno-spe, to match GCC. Subscribers: nemanjai, kbarton, cfe-commits Differential Revision: https://reviews.llvm.org/D49754 llvm-svn: 371066
* [DebugInfo] Emit DW_TAG_enumeration_type for referenced global enumerator.Yuanfang Chen2019-09-041-9/+17
| | | | | | | | | | | | | | | | | This essentially reverts changes from r361400 while keeping behavior for CodeView. Reviewers: akhuang, rnk, probinson Reviewed by: rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67141 llvm-svn: 370981
* [NewPM][Sancov] Make Sancov a Module Pass instead of 2 PassesLeonard Chan2019-09-041-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch merges the sancov module and funciton passes into one module pass. The reason for this is because we ran into an out of memory error when attempting to run asan fuzzer on some protobufs (pc.cc files). I traced the OOM error to the destructor of SanitizerCoverage where we only call appendTo[Compiler]Used which calls appendToUsedList. I'm not sure where precisely in appendToUsedList causes the OOM, but I am able to confirm that it's calling this function *repeatedly* that causes the OOM. (I hacked sancov a bit such that I can still create and destroy a new sancov on every function run, but only call appendToUsedList after all functions in the module have finished. This passes, but when I make it such that appendToUsedList is called on every sancov destruction, we hit OOM.) I don't think the OOM is from just adding to the SmallSet and SmallVector inside appendToUsedList since in either case for a given module, they'll have the same max size. I suspect that when the existing llvm.compiler.used global is erased, the memory behind it isn't freed. I could be wrong on this though. This patch works around the OOM issue by just calling appendToUsedList at the end of every module run instead of function run. The same amount of constants still get added to llvm.compiler.used, abd we make the pass usage and logic simpler by not having any inter-pass dependencies. Differential Revision: https://reviews.llvm.org/D66988 llvm-svn: 370971
* [AMDGPU] Set default flat work group size to (1,256) for HIPYaxun Liu2019-09-031-3/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D67048 llvm-svn: 370808
* [WebAssembly] Add SIMD QFMA/QFMSThomas Lively2019-08-311-1/+23
| | | | | | | | | | | | | | | | | | | Summary: Adds clang builtins and LLVM intrinsics for these experimental instructions. They are not implemented in engines yet, but that is ok because the user must opt into using them by calling the builtins. Reviewers: aheejin, dschuff Reviewed By: aheejin Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67020 llvm-svn: 370556
* [CodeGen]: fix error message for "=r" asm constraintAlexander Potapenko2019-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Nico Weber reported that the following code: char buf[9]; asm("" : "=r" (buf)); yields the "impossible constraint in asm: can't store struct into a register" error message, although |buf| is not a struct (see http://crbug.com/999160). Make the error message more generic and add a test for it. Also make sure other tests in x86_64-PR42672.c check for the full error message. Reviewers: eli.friedman, thakis Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66948 llvm-svn: 370444
* [CodeGen]: don't treat structures returned in registers as memory inputsAlexander Potapenko2019-08-291-5/+36
| | | | | | | | | | | | | | | | | | | | Summary: The "=r" output constraint for a structure variable passed to inline asm shouldn't be converted to "=*r", as this changes the asm directive semantics and prevents DSE optimizations. Instead, preserve the constraints and return such structures as integers of corresponding size, which are converted back to structures when storing the result. Fixes PR42672. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65234 llvm-svn: 370335
* Fix always_inline 'target' compatibility check code for LambdasErich Keane2019-08-281-1/+1
| | | | | | | | | The previous version of this used CurFuncDecl in CodeGenFunction, however this doesn't include lambdas. However, CurCodeDecl DOES. Switch the check to use CurCodeDecl so that the actual function being emitted gets checked, preventing an error in ISEL. llvm-svn: 370261
* Debug Info: Support for DW_AT_export_symbols for anonymous structsShafik Yaghmour2019-08-271-1/+6
| | | | | | | | | | | | | | | | | | | | This implements the DWARF 5 feature described in: http://dwarfstd.org/ShowIssue.php?issue=141212.1 To support recognizing anonymous structs: struct A { struct { // Anonymous struct int y; }; } a; This patch adds support in CGDebugInfo::CreateLimitedType(...) for this new flag and an accompanying test to verify this feature. Differential Revision: https://reviews.llvm.org/D66667 llvm-svn: 370107
* AMDGPU: Always emit amdgpu-flat-work-group-sizeMatt Arsenault2019-08-271-2/+8
| | | | | | | The backend default maximum should be the hardware maximum, so the frontend should set the implementation defined default maximum. llvm-svn: 370101
* Implement codegen for MSVC unions with reference members.Aaron Ballman2019-08-271-14/+16
| | | | | | | | Currently, clang accepts a union with a reference member when given the -fms-extensions flag. This change fixes the codegen for this case. Patch by Dominic Ferreira. llvm-svn: 370052
* hwasan, codegen: Keep more lifetime markers used for hwasanVitaly Buka2019-08-262-0/+2
| | | | | | | | | | | | Reviewers: eugenis Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66697 llvm-svn: 369980
* msan, codegen, instcombine: Keep more lifetime markers used for msanVitaly Buka2019-08-262-11/+6
| | | | | | | | | | | | Reviewers: eugenis Subscribers: hiraditya, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D66695 llvm-svn: 369979
* [OPENMP][NVPTX]Fix critical region codegen.Alexey Bataev2019-08-261-2/+24
| | | | | | | | | | | | | | | | | Summary: Previously critical regions were emitted with the barrier making it a worksharing construct though it is not. Also, it leads to incorrect behavior in Cuda9+. Patch fixes this problem. Reviewers: ABataev, jdoerfert Subscribers: jholewinski, guansong, cfe-commits, grokos Tags: #clang Differential Revision: https://reviews.llvm.org/D66673 llvm-svn: 369946
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-231-1/+1
| | | | llvm-svn: 369803
* [OPENMP5]Use nonmonotonic modifier by default for non-static andAlexey Bataev2019-08-231-8/+21
| | | | | | | | | | non-ordered loops. According to OpenMP 5.0, 2.9.2 Worksharing-Loop Construct, Desription, If the static schedule kind is specified or if the ordered clause is specified, and if the nonmonotonic modifier is not specified, the effect is as if the monotonic modifier is specified. Otherwise, unless the monotonic modifier is specified, the effect is as if the nonmonotonic modifier is specified. The first part of this requirement is implemented in runtime. Patch adds support for the second, nonmonotonic, part of this requirement. llvm-svn: 369801
* [OPENMP5.0]Add support for device_type clause in declare targetAlexey Bataev2019-08-233-5/+32
| | | | | | | | | | construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
* [Clang][CodeGen] set alias linkage on QualTypeNick Desaulniers2019-08-221-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It seems that CodeGen was always using ExternalLinkage when emitting a GlobalDecl with __attribute__((alias)). This leads to symbol redefinitions (ODR) that cause failures at link time for static aliases. This is readily attempting to link an ARM (32b) allyesconfig Linux kernel built with Clang. Reported-by: nathanchance Suggested-by: ihalip Link: https://bugs.llvm.org/show_bug.cgi?id=42377 Link: https://github.com/ClangBuiltLinux/linux/issues/631 Reviewers: rsmith, aaron.ballman, erichkeane Reviewed By: aaron.ballman Subscribers: javed.absar, kristof.beyls, cfe-commits, srhines, ihalip, nathanchance Tags: #clang Differential Revision: https://reviews.llvm.org/D66492 llvm-svn: 369705
* IR. Change strip* family of functions to not look through aliases.Peter Collingbourne2019-08-221-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | I noticed another instance of the issue where references to aliases were being replaced with aliasees, this time in InstCombine. In the instance that I saw it turned out to be only a QoI issue (a symbol ended up being missing from the symbol table due to the last reference to the alias being removed, preventing HWASAN from symbolizing a global reference), but it could easily have manifested as incorrect behaviour. Since this is the third such issue encountered (previously: D65118, D65314) it seems to be time to address this common error/QoI issue once and for all and make the strip* family of functions not look through aliases. Includes a test for the specific issue that I saw, but no doubt there are other similar bugs fixed here. As with D65118 this has been tested to make sure that the optimization isn't load bearing. I built Clang, Chromium for Linux, Android and Windows as well as the test-suite and there were no size regressions. Differential Revision: https://reviews.llvm.org/D66606 llvm-svn: 369697
* Revert r369458 "[DebugInfo] Add debug location to dynamic atexit destructor"Hans Wennborg2019-08-222-4/+1
| | | | | | | | | | | | | | | | It causes the build to fail with "inlinable function call in a function with debug info must have a !dbg location" in Chromium. See llvm-commits thread for more info. (This also reverts the follow-up in r369474.) > Fixes PR43012 > > Differential Revision: https://reviews.llvm.org/D66328 llvm-svn: 369633
* [LTO] Always mark regular LTO units with EnableSplitLTOUnit=1 under the new ↵Leonard Chan2019-08-211-1/+1
| | | | | | | | | | | | pass manager Match the behavior of D65009 under the new pass manager. This addresses the test clang/test/CodeGen/split-lto-unit.c when running under the new PM. Differential Revision: https://reviews.llvm.org/D66488 llvm-svn: 369550
* [DebugInfo] Add debug location to dynamic atexit destructorAlexandre Ganea2019-08-202-1/+4
| | | | | | | | Fixes PR43012 Differential Revision: https://reviews.llvm.org/D66328 llvm-svn: 369458
* [Support][Time profiler] Make FE codegen blocks to be inside frontend blocksAnton Afanasyev2019-08-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Add `Frontend` time trace entry to `HandleTranslationUnit()` function. Add test to check all codegen blocks are inside frontend blocks. Also, change `--time-trace-granularity` option a bit to make sure very small time blocks are outputed to json-file when using `--time-trace-granularity=0`. This fixes http://llvm.org/pr41969 Reviewers: russell.gallop, lebedev.ri, thakis Reviewed By: russell.gallop Subscribers: vsapsai, aras-p, lebedev.ri, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63325 llvm-svn: 369308
* Don't keep stale pointers to LoopInfos.Aaron Ballman2019-08-192-7/+8
| | | | | | | | CGLoopInfo was keeping pointers to parent loop LoopInfos, but when the loop info vector grew, it reallocated the storage and invalidated all of the parent pointers, causing use-after-free. Manage the lifetimes of the LoopInfos separately so that the pointers aren't stale. Patch by Bevin Hansson. llvm-svn: 369259
* [WebAssembly] Correctly handle va_arg of zero-sized structuresGuanzhong Chen2019-08-151-2/+3
| | | | | | | | | | | | | | | | | | | | | Summary: D66168 passes size 0 structs indirectly, while the wasm backend expects it to be passed directly. This causes subsequent variadic arguments to be read incorrectly. This diff changes it so that size 0 structs are passed directly. Reviewers: dschuff, tlively, sbc100 Reviewed By: dschuff Subscribers: jgravelle-google, aheejin, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66255 llvm-svn: 369042
* Replace llvm::integer_sequence and friends with the C++14 standard versionBenjamin Kramer2019-08-151-2/+2
| | | | | | The implementation in libc++ takes O(1) compile time, ours was O(n). llvm-svn: 368990
* [Clang] Pragma vectorize_predicate implies vectorizeSjoerd Meijer2019-08-151-6/+15
| | | | | | | | | | New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)", and it is ignored when vectorization is disabled with e.g. "vectorize(disable) vectorize_predicate(enable)". Differential Revision: https://reviews.llvm.org/D65776 llvm-svn: 368970
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-147-16/+16
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [OPENMP]Support for non-rectangular loops.Alexey Bataev2019-08-141-0/+30
| | | | | | | | Added basic support for non-rectangular loops. It requires an additional analysis of min/max boundaries for non-rectangular loops. Since only linear dependency is allowed, we can do this analysis. llvm-svn: 368903
* [clang] - An update after LLVM change.George Rimar2019-08-141-1/+5
| | | | | | SectionRef::getName() was changed to return Expected<> (D66089) llvm-svn: 368825
* [NewPM][PassInstrumentation] IR printing support from clang driverTaewook Oh2019-08-141-1/+5
| | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D50923 enabled the IR printing support for the new pass manager, but only for the case when `opt` tool is used as a driver. This patch is to enable the IR printing when `clang` is used as a driver. Reviewers: fedor.sergeev, philip.pfaffe Subscribers: cfe-commits, yamauchi, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65975 llvm-svn: 368804
* [WebAssembly] Make clang emit correct va_arg code for structsGuanzhong Chen2019-08-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In the WebAssembly backend, when lowering variadic function calls, non-single member aggregate type arguments are always passed by pointer. However, when emitting va_arg code in clang, the arguments are instead read as if they are passed directly. This results in the pointer being read as the actual structure. Fixes https://github.com/emscripten-core/emscripten/issues/9042. Reviewers: tlively, sbc100, kripken, aheejin, dschuff Reviewed By: dschuff Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66168 llvm-svn: 368750
* [CodeGen] Disable UBSan for coroutine functionsBrian Gesiak2019-08-131-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As explained in http://lists.llvm.org/pipermail/llvm-dev/2018-March/121924.html, the LLVM coroutines transforms are not yet able to move the instructions for UBSan null checking past coroutine suspend boundaries. For now, disable all UBSan checks when generating code for coroutines functions. I also considered an approach where only '-fsanitize=null' would be disabled, However in practice this led to other LLVM errors when writing object files: "Cannot represent a difference across sections". For now, disable all UBSan checks until coroutine transforms are updated to handle them. Test Plan: 1. check-clang 2. Compile the program in https://gist.github.com/modocache/54a036c3bf9c06882fe85122e105d153 using the '-fsanitize=null' option and confirm it does not crash during LLVM IR generation. Reviewers: GorNishanov, vsk, eric_niebler, lewissbaker Reviewed By: vsk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D44672 llvm-svn: 368675
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-092-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
OpenPOWER on IntegriCloud