summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Revert r343518.Akira Hatanaka2018-10-015-38/+26
| | | | | | | | | Bots are still failing. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/24420 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12958 llvm-svn: 343531
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-015-26/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r341754, which was reverted in r341757 because it broke a couple of bots. r341754 was calling markEscapingByrefs after the call to PopFunctionScopeInfo, which caused the popped function scope to be cleared out when the following code was compiled, for example: $ cat test.m struct A { id data[10]; }; void foo() { __block A v; ^{ (void)v; }; } This commit calls markEscapingByrefs before calling PopFunctionScopeInfo to prevent that from happening. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343518
* [OPENMP][NVPTX] Handle `requires datasharing` flag correctly withAlexey Bataev2018-10-011-1/+27
| | | | | | | | lightweight runtime. The datasharing flag must be set to `1` when executing SPMD-mode compatible directive with reduction|lastprivate clauses. llvm-svn: 343492
* [OPENMP] Simplify code, NFC.Alexey Bataev2018-10-011-2/+0
| | | | llvm-svn: 343483
* [OPENMP] Fix enum identifier, NFC.Alexey Bataev2018-10-011-1/+1
| | | | llvm-svn: 343479
* Add support for unified_shared_memory clause on requires directivePatrick Lyster2018-10-011-0/+1
| | | | llvm-svn: 343472
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-3/+2
| | | | | | | | | There are a few leftovers of rC343147 that are not (\w+)\.begin but in the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them to use the container form in this commit. The 12 occurrences have been inspected manually for safety. llvm-svn: 343425
* [cxx2a] P0614R1: Support init-statements in range-based for loops.Richard Smith2018-09-283-0/+6
| | | | | | | We don't yet support this for the case where a range-based for loop is implicitly rewritten to an ObjC for..in statement. llvm-svn: 343350
* [OpenMP] Make default parallel for schedule in NVPTX target regions in SPMD ↵Gheorghe-Teodor Bercea2018-09-274-1/+27
| | | | | | | | | | | | | | | | mode achieve coalescing Summary: Set default schedule for parallel for loops to schedule(static, 1) when using SPMD mode on the NVPTX device offloading toolchain to ensure coalescing. Reviewers: ABataev, Hahnfeld, caomhin Reviewed By: ABataev Subscribers: jholewinski, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D52629 llvm-svn: 343260
* [OpenMP] Make default distribute schedule for NVPTX target regions in SPMD ↵Gheorghe-Teodor Bercea2018-09-274-0/+27
| | | | | | | | | | | | | | | | mode achieve coalescing Summary: For the OpenMP NVPTX toolchain choose a default distribute schedule that ensures coalescing on the GPU when in SPMD mode. This significantly increases the performance of offloaded target code and reduces the number of registers used on the GPU side. Reviewers: ABataev, caomhin, Hahnfeld Reviewed By: ABataev, Hahnfeld Subscribers: Hahnfeld, jholewinski, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D52434 llvm-svn: 343253
* Revert "[DebugInfo] Generate debug information for labels."Vitaly Buka2018-09-273-39/+0
| | | | | | | | This reverts commit r343148. It crashes on sanitizer-x86_64-linux-autoconf. llvm-svn: 343183
* [DebugInfo] Generate debug information for labels.Hsiangkai Wang2018-09-263-0/+39
| | | | | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. After fixing problems in LiveDebugVariables. After fixing NULL symbol problems in AddressPool when enabling split-dwarf-file. Differential Revision: https://reviews.llvm.org/D45045 llvm-svn: 343148
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-265-7/+7
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [X86] For lzcnt/tzcnt intrinsics use cttz/ctlz intrinsics with zero_undef ↵Craig Topper2018-09-261-0/+12
| | | | | | | | | | | | flag set to false. Previously we used a select and the zero_undef=true intrinsic. In -O2 this pattern will get optimized to zero_undef=false. But in -O0 this optimization won't happen. This results in a compare and cmov being wrapped around a tzcnt/lzcnt instruction. By using the zero_undef=false intrinsic directly without the select, we can improve the -O0 codegen to just an lzcnt/tzcnt instruction. Differential Revision: https://reviews.llvm.org/D52392 llvm-svn: 343126
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-266-0/+20
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with ↵Kristina Brooks2018-09-251-24/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `-fconstant-cfstrings`" Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately 1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF). This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 343038
* [CodeGen] Revert commit https://reviews.llvm.org/rL342717Calixte Denizet2018-09-245-34/+22
| | | | llvm-svn: 342912
* Fix the type of 1<<31 integer constants.Benjamin Kramer2018-09-241-1/+1
| | | | | | | Shifting into the sign bit is technically undefined behavior. No known compiler exploits it though. llvm-svn: 342909
* Revert "rL342883: [Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with ↵Kristina Brooks2018-09-241-39/+24
| | | | | | | | `-fconstant-cfstrings`." Seems to be causing buildbot failures, need to look into it. llvm-svn: 342893
* [Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`.Kristina Brooks2018-09-241-24/+39
| | | | | | | | | | | | | | | | | | | [Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 342883
* Make compare function in r342648 have strict weak ordering.Richard Trieu2018-09-211-2/+9
| | | | | | | Comparison functions used in sorting algorithms need to have strict weak ordering. Remove the assert and allow comparisons on all lists. llvm-svn: 342774
* Add necessary support for storing code-model to module IR.Caroline Tice2018-09-211-0/+16
| | | | | | | | | | | | Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is not propagated properly to LTO. This patch does what is necessary in the front end to pass the code-model to the module, so that the back end can store it in the Module . Differential Revision: https://reviews.llvm.org/D52323 llvm-svn: 342758
* [NFC] remove unused variableJF Bastien2018-09-211-1/+0
| | | | | | It was causing a warning. llvm-svn: 342750
* [OPENMP][NVPTX] Enable support for lastprivates in SPMD constructs.Alexey Bataev2018-09-211-69/+127
| | | | | | | Previously we could not use lastprivates in SPMD constructs, patch allows supporting lastprivates in SPMD with uninitialized runtime. llvm-svn: 342738
* NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValueJF Bastien2018-09-211-101/+13
| | | | | | | | | | | | | Summary: This code was in CGDecl.cpp and really belongs in LLVM. It happened to have isBytewiseValue which served a very similar purpose but wasn't as powerful as clang's version. Remove the clang version, and augment isBytewiseValue to be as powerful so that clang does the same thing it used to. LLVM part of this patch: D51751 Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51752 llvm-svn: 342734
* [CodeGen] Add to emitted DebugLoc information about coverage when it's requiredCalixte Denizet2018-09-215-22/+34
| | | | | | | | | | | | | | | | | | | | Summary: Some lines have a hit counter where they should not have one. Cleanup stuff is located to the last line of the body which is most of the time a '}'. And Exception stuff is added at the beginning of a function and at the end (represented by '{' and '}'). So in such cases, the DebugLoc used in GCOVProfiling.cpp must be marked as not covered. This patch is a followup of https://reviews.llvm.org/D49915. Tests in projects/compiler_rt are fixed by: https://reviews.llvm.org/D49917 Reviewers: marco-c, davidxl Reviewed By: marco-c Subscribers: dblaikie, cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D49916 llvm-svn: 342717
* [OPENMP] Fix spelling of getLoopCounter (NFC)Mike Rice2018-09-201-2/+2
| | | | llvm-svn: 342666
* [OPENMP] Add support for mapping memory pointed by member pointer.Alexey Bataev2018-09-201-11/+259
| | | | | | Added support for map(s, s.ptr[0:1]) kind of mapping. llvm-svn: 342648
* [PowerPC] [Clang] Add vector int128 pack/unpack builtinsQingShan Zhang2018-09-201-0/+22
| | | | | | | | | | | | unsigned long long builtin_unpack_vector_int128 (vector int128_t, int); vector int128_t builtin_pack_vector_int128 (unsigned long long, unsigned long long); Builtins should behave the same way as in GCC. Patch By: wuzish (Zixuan Wu) Differential Revision: https://reviews.llvm.org/D52074 llvm-svn: 342614
* [MS] Defer dllexport inline friend functions like other inline methodsReid Kleckner2018-09-181-20/+9
| | | | | | | | | | | | | | | This special case was added in r264841, but the code breaks our invariants by calling EmitTopLevelDecl without first creating a HandlingTopLevelDeclRAII scope. This fixes the PCH crash in https://crbug.com/884427. I was never able to make a satisfactory reduction, unfortunately. I'm not very worried about this regressing since this change makes the code simpler while passing the existing test that shows we do emit dllexported friend function definitions. Now we just defer their emission until the tag is fully complete, which is generally good. llvm-svn: 342516
* [XRay][clang] Emit "never-instrument" attributeDean Michael Berris2018-09-142-15/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, we only emit the XRay attributes in LLVM IR when the -fxray-instrument flag is provided. This may cause issues with thinlto when the final binary is being built/linked with -fxray-instrument, and the constitutent LLVM IR gets re-lowered with xray instrumentation. With this change, we can honour the "never-instrument "attributes provided in the source code and preserve those in the IR. This way, even in thinlto builds, we retain the attributes which say whether functions should never be XRay instrumented. This change addresses llvm.org/PR38922. Reviewers: mboerger, eizan Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D52015 llvm-svn: 342200
* [NFC]Refactor MultiVersion Resolver Emission to combine typesErich Keane2018-09-133-93/+75
| | | | | | | | | Previously, both types (plus the future target-clones) of multiversioning had a separate ResolverOption structure and emission function. This patch combines the two, at the expense of a slightly more expensive sorting function. llvm-svn: 342152
* [OPENMP] Fix PR38903: Crash on instantiation of the non-dependentAlexey Bataev2018-09-132-24/+13
| | | | | | | | | | | declare reduction. If the declare reduction construct with the non-dependent type is defined in the template construct, the compiler might crash on the template instantition. Reworked the whole instantiation scheme for the declare reduction constructs to fix this problem correctly. llvm-svn: 342151
* [AArch64] Enable return address signing for static ctorsOliver Stannard2018-09-131-0/+6
| | | | | | | | | | | Functions generated by clang and included in the .init_array section (such as static constructors) do not follow the usual code path for adding target-specific function attributes, so we have to add the return address signing attribute here too, as is currently done for the sanitisers. Differential revision: https://reviews.llvm.org/D51418 llvm-svn: 342126
* [CodeGen] Align rtti and vtable dataDavid Green2018-09-126-20/+31
| | | | | | | | | | Previously the alignment on the newly created rtti/typeinfo data was largely not set, meaning that DataLayout::getPreferredAlignment was free to overalign it to 16 bytes. This causes unnecessary code bloat. Differential Revision: https://reviews.llvm.org/D51416 llvm-svn: 342053
* [CodeGen][ARM] Coerce FP16 vectors to integer vectors when neededMikhail Maltsev2018-09-121-32/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On targets that do not support FP16 natively LLVM currently legalizes vectors of FP16 values by scalarizing them and promoting to FP32. This causes problems for the following code: void foo(int, ...); typedef __attribute__((neon_vector_type(4))) __fp16 float16x4_t; void bar(float16x4_t x) { foo(42, x); } According to the AAPCS (appendix A.2) float16x4_t is a containerized vector fundamental type, so 'foo' expects that the 4 16-bit FP values are packed into 2 32-bit registers, but instead bar promotes them to 4 single precision values. Since we already handle scalar FP16 values in the frontend by bitcasting them to/from integers, this patch adds similar handling for vector types and homogeneous FP16 vector aggregates. One existing test required some adjustments because we now generate more bitcasts (so the patch changes the test to target a machine with native FP16 support). Reviewers: eli.friedman, olista01, SjoerdMeijer, javed.absar, efriedma Reviewed By: javed.absar, efriedma Subscribers: efriedma, kristof.beyls, cfe-commits, chrib Differential Revision: https://reviews.llvm.org/D50507 llvm-svn: 342034
* Remove all uses of DIFlagBlockByrefStructAdrian Prantl2018-09-102-19/+24
| | | | | | | | | | | | This patch removes the last reason why DIFlagBlockByrefStruct from Clang by directly implementing the drilling into the member type done in DwarfDebug::DbgVariable::getType() into the frontend. rdar://problem/31629055 Differential Revision: https://reviews.llvm.org/D51807 llvm-svn: 341842
* Revert r341754.Akira Hatanaka2018-09-095-38/+26
| | | | | | | | | The commit broke a couple of bots: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12347 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/7310 llvm-svn: 341757
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-09-085-26/+38
| | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 341754
* Do not use optimized atomic libcalls for misaligned atomics.Richard Smith2018-09-071-4/+10
| | | | | | | | | | | | | | | | | Summary: The optimized (__atomic_foo_<n>) libcalls assume that the atomic object is properly aligned, so should never be called on an underaligned object. This addresses one of several problems identified in PR38846. Reviewers: jyknight, t.p.northover Subscribers: jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D51817 llvm-svn: 341734
* Make -Watomic-alignment say whether the atomic operation was oversizedRichard Smith2018-09-071-4/+8
| | | | | | or misaligned. llvm-svn: 341710
* [X86] Custom emit __builtin_rdtscp so we can emit an explicit store for the ↵Craig Topper2018-09-071-0/+6
| | | | | | | | | | out parameter This is the clang side of D51803. The llvm intrinsic now returns two results. So we need to emit an explicit store in IR for the out parameter. This is similar to addcarry/subborrow/rdrand/rdseed. Differential Revision: https://reviews.llvm.org/D51805 llvm-svn: 341699
* [X86] Modify addcarry/subborrow builtins to emit an 2 result and intrinsic ↵Craig Topper2018-09-071-0/+35
| | | | | | | | | | and an store instruction. This is the clang side of D51769. The llvm intrinsics now return two results instead of using an out parameter. Differential Revision: https://reviews.llvm.org/D51771 llvm-svn: 341678
* [MSan] add KMSAN support to Clang driverAlexander Potapenko2018-09-073-4/+26
| | | | | | | | | | | | | | | Boilerplate code for using KMSAN instrumentation in Clang. We add a new command line flag, -fsanitize=kernel-memory, with a corresponding SanitizerKind::KernelMemory, which, along with SanitizerKind::Memory, maps to the memory_sanitizer feature. KMSAN is only supported on x86_64 Linux. It's incompatible with other sanitizers, but supports code coverage instrumentation. llvm-svn: 341641
* Remove deprecated APIStephen Kelly2018-09-061-4/+0
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50353 llvm-svn: 341573
* Re-land r334417 "[MS] Use mangled names and comdats for string merging with ↵Reid Kleckner2018-09-061-7/+5
| | | | | | | | | ASan" The issue with -fprofile-generate was fixed and the dependent CL relanded in r340232. llvm-svn: 341572
* Revert "[DebugInfo] Generate debug information for labels. (Fix PR37395)"Sam McCall2018-09-063-39/+0
| | | | | | | | | This reverts commit r341519, which generates debug info that causes backend crashes. (with -split-dwarf-file) Details in https://reviews.llvm.org/D50495 llvm-svn: 341549
* [DebugInfo] Generate debug information for labels. (Fix PR37395)Hsiangkai Wang2018-09-063-0/+39
| | | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. After fixing problems in LiveDebugVariables. Differential Revision: https://reviews.llvm.org/D45045 llvm-svn: 341519
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* Add header guards to some headers that are missing themArgyrios Kyrtzidis2018-09-031-0/+5
| | | | llvm-svn: 341324
OpenPOWER on IntegriCloud