summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [X86] Add ktest intrinsics to match gcc and icc.Craig Topper2018-08-311-0/+44
| | | | | | | | | | | | These aren't documented in the Intel Intrinsics Guide, but are supported by gcc and icc. Includes these intrinsics: _ktestc_mask8_u8, _ktestz_mask8_u8, _ktest_mask8_u8 _ktestc_mask16_u8, _ktestz_mask16_u8, _ktest_mask16_u8 _ktestc_mask32_u8, _ktestz_mask32_u8, _ktest_mask32_u8 _ktestc_mask64_u8, _ktestz_mask64_u8, _ktest_mask64_u8 llvm-svn: 341265
* [X86] Add k-mask conversion and load/store instrinsics to match gcc and icc.Craig Topper2018-08-311-0/+11
| | | | | | | | | | | | This adds: _cvtmask8_u32, _cvtmask16_u32, _cvtmask32_u32, _cvtmask64_u64 _cvtu32_mask8, _cvtu32_mask16, _cvtu32_mask32, _cvtu64_mask64 _load_mask8, _load_mask16, _load_mask32, _load_mask64 _store_mask8, _store_mask16, _store_mask32, _store_mask64 These are currently missing from the Intel Intrinsics Guide webpage. llvm-svn: 341251
* [X86] Add kshift intrinsics to match gcc and icc.Craig Topper2018-08-311-0/+44
| | | | | | | | | | | | | | This adds the following intrinsics: _kshiftli_mask8 _kshiftli_mask16 _kshiftli_mask32 _kshiftli_mask64 _kshiftri_mask8 _kshiftri_mask16 _kshiftri_mask32 _kshiftri_mask64 llvm-svn: 341234
* [DEBUGINFO] Add support for emission of the debug directives only.Alexey Bataev2018-08-311-0/+3
| | | | | | | | | | | | | | | | Summary: Added option -gline-directives-only to support emission of the debug directives only. It behaves very similar to -gline-tables-only, except that it sets llvm debug info emission kind to llvm::DICompileUnit::DebugDirectivesOnly. Reviewers: echristo Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D51177 llvm-svn: 341212
* [OPENMP] Fix PR38710: static functions are not emitted as implicitlyAlexey Bataev2018-08-303-19/+23
| | | | | | | | | 'declare target'. All the functions, referenced in implicit|explicit target regions must be emitted during code emission for the device. llvm-svn: 341093
* [OPENMP][NVPTX] Add options -f[no-]openmp-cuda-force-full-runtime.Alexey Bataev2018-08-301-1/+2
| | | | | | | Added options -f[no-]openmp-cuda-force-full-runtime to [not] force use of the full runtime for OpenMP offloading to CUDA devices. llvm-svn: 341073
* [OPENMP] Do not create offloading entry for declare target variablesAlexey Bataev2018-08-291-1/+9
| | | | | | | | | declarations. We should not create offloading entries for declare target var declarations as it causes compiler crash. llvm-svn: 340968
* [OPENMP][NVPTX] Add support for lightweight runtime.Alexey Bataev2018-08-292-49/+321
| | | | | | | | If the target construct can be executed in SPMD mode + it is a loop based directive with static scheduling, we can use lightweight runtime support. llvm-svn: 340953
* [MinGW] Don't mark external variables as DSO localMartin Storsjo2018-08-291-0/+8
| | | | | | | | | | | | Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
* [OPENMP] Create non-const ident_t objects.Mike Rice2018-08-291-12/+13
| | | | | | | | | | | Currently ident_t objects are created const when debug info is not enabled, but the libittnotify libray in the OpenMP runtime writes to the reserved_2 field (See __kmp_itt_region_forking in openmp/runtime/src/kmp_itt.inl). Now create ident_t objects non-const. Differential Revision: https://reviews.llvm.org/D51331 llvm-svn: 340934
* [X86] Add kadd intrinsics to match gcc and icc.Craig Topper2018-08-281-1/+29
| | | | | | | | | | | | This adds the following intrinsics: _kadd_mask64 _kadd_mask32 _kadd_mask16 _kadd_mask8 These are missing from the Intel Intrinsics Guide, but are implemented by both gcc and icc. llvm-svn: 340879
* [X86] Add kortest intrinsics for 8, 32, and 64 bit masks. Add new intrinsic ↵Craig Topper2018-08-281-6/+13
| | | | | | | | names for 16 bit masks. This matches gcc and icc despite not being documented in the Intel Intrinsics Guide. llvm-svn: 340798
* [X86] Add intrinsics for kand/kandn/knot/kor/kxnor/kxor with 8, 32, and ↵Craig Topper2018-08-271-12/+32
| | | | | | | | | | 64-bit mask registers. This also adds a second intrinsic name for the 16-bit mask versions. These intrinsics match gcc and icc. They just aren't published in the Intel Intrinsics Guide so I only recently found they existed. llvm-svn: 340719
* [LTO] Fix -save-temps with LTO and unnamed globals.Eli Friedman2018-08-241-2/+4
| | | | | | | | | If all LLVM passes are disabled, we can't emit a summary because there could be unnamed globals in the IR. Differential Revision: https://reviews.llvm.org/D51198 llvm-svn: 340640
* Currently clang does not emit unused static constants. GCC emits theseElizabeth Andrews2018-08-221-0/+13
| | | | | | | | | | | | | | | | constants by default when there is no optimization. GCC's option -fno-keep-static-consts can be used to not emit unused static constants. In Clang, since default behavior does not keep unused static constants, -fkeep-static-consts can be used to emit these if required. This could be useful for producing identification strings like SVN identifiers inside the object file even though the string isn't used by the program. Differential Revision: https://reviews.llvm.org/D40925 llvm-svn: 340439
* [CodeGen] Look at the type of a block capture field rather than the typeAkira Hatanaka2018-08-221-16/+16
| | | | | | | | | | | | | | of the captured variable when determining whether the capture needs special handing when the block is copied or disposed. This fixes bugs in the handling of variables captured by a block that is nested inside a lambda that captures the variables by reference. rdar://problem/43540889 Differential Revision: https://reviews.llvm.org/D51025 llvm-svn: 340408
OpenPOWER on IntegriCloud