summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Filter out invalid 'target' items from being passed to LLVMErich Keane2017-10-272-4/+14
| | | | | | | | | | | | | | | | | Craig noticed that CodeGen wasn't properly ignoring the values sent to the target attribute. This patch ignores them. This patch also sets the 'default' for this checking to 'supported', since only X86 has implemented the support for checking valid CPU names and Feature Names. One test was changed to i686, since it uses a lakemont, which would otherwise be prohibited in x86_64. Differential Revision: https://reviews.llvm.org/D39357 llvm-svn: 316783
* [CodeGen] Add support for IncompleteArrayType in Obj-C ivars.Volodymyr Sapsai2017-10-271-0/+5
| | | | | | | | | | | | | | | | | Fixes an assertion failure when ivar is a struct containing incomplete array. Also completes support for direct flexible array members. rdar://problem/21054495 Reviewers: rjmccall, theraven Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38774 llvm-svn: 316723
* [CGBlocks] Improve line info in backtraces containing *_helper_blockVedant Kumar2017-10-261-6/+2
| | | | | | | | | | | | | | | | | | Instead of only setting a non-zero debug location on the return instruction in *_helper_block functions, set a proper location on all instructions within these functions. Pick the start location of the block literal expr for maximum clarity. The debugger does not step into *_helper_block functions during normal single-stepping because we mark their parameters as artificial. This is what we want (the functions are implicitly generated and uninteresting to most users). The stepping behavior is unchanged by this patch. rdar://32907581 Differential Revision: https://reviews.llvm.org/D39310 llvm-svn: 316704
* Simplify codegen and debug info generation for block context parameters.Adrian Prantl2017-10-263-24/+13
| | | | | | | | | | | | | | | | | | | | The exisiting code goes out of its way to put block parameters into an alloca only at -O0, and then describes the funciton argument with a dbg.declare, which is undocumented in the LLVM-CFE contract and does not actually behave as intended after LLVM r642022. This patch just generates the alloca unconditionally, the mem2reg pass will eliminate it at -O1 and up anyway and points the dbg.declare to the alloca as intended (which mem2reg will then correctly rewrite into a dbg.value). This reapplies r316684 with some dead code removed. rdar://problem/35043980 Differential Revision: https://reviews.llvm.org/D39305 llvm-svn: 316689
* Revert "Simplify codegen and debug info generation for block context ↵Adrian Prantl2017-10-263-14/+22
| | | | | | | | parameters." This reverts commit r316684 while investigating buildbot breakage. llvm-svn: 316686
* Simplify codegen and debug info generation for block context parameters.Adrian Prantl2017-10-263-22/+14
| | | | | | | | | | | | | | | | | | The exisiting code goes out of its way to put block parameters into an alloca only at -O0, and then describes the funciton argument with a dbg.declare, which is undocumented in the LLVM-CFE contract and does not actually behave as intended after LLVM r642022. This patch just generates the alloca unconditionally, the mem2reg pass will eliminate it at -O1 and up anyway and points the dbg.declare to the alloca as intended (which mem2reg will then correctly rewrite into a dbg.value). rdar://problem/35043980 Differential Revision: https://reviews.llvm.org/D39305 llvm-svn: 316684
* CodeGen: fix PPC Darwin variadicsSaleem Abdulrasool2017-10-251-1/+37
| | | | | | | | | Darwin uses char * for the variadic list type (va_list). We use the PPC SVR4 ABI for PPC, which uses a structure type for the va_list. When constructing the GEP, we would fail due to the incorrect handling for the va_list. Correct this to use the right type. llvm-svn: 316599
* CodeGen: fix a case of incorrect checks for ivarsSaleem Abdulrasool2017-10-251-4/+8
| | | | | | | | Ensure that we check the ivar containing decl for the DLL storage attribute rather than the ivar itself as the dll storage is associated to the interface decl not the ivar decl. llvm-svn: 316545
* [OPENMP] Fix PR35013: Fix passing VLAs captures to outlined functions.Alexey Bataev2017-10-241-1/+7
| | | | | | | Fixed passing of VLAs and variably-modified types to outlined functions. Synchronized passing with the types codegen. llvm-svn: 316488
* CodeGen: Fix missing debug loc due to allocaYaxun Liu2017-10-241-2/+1
| | | | | | | | | | | | Builder save/restores insertion pointer when emitting addr space cast for alloca, but does not save/restore debug loc, which causes verifier failure for certain call instructions. This patch fixes that. Differential Revision: https://reviews.llvm.org/D39069 llvm-svn: 316484
* [OpenMP] Avoid VLAs for some reductions on array sectionsJonas Hahnfeld2017-10-232-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases the compiler can deduce the length of an array section as constants. With this information, VLAs can be avoided in place of a constant sized array or even a scalar value if the length is 1. Example: int a[4], b[2]; pragma omp parallel reduction(+: a[1:2], b[1:1]) { } For chained array sections, this optimization is restricted to cases where all array sections except the last have a constant length 1. This trivially guarantees that there are no holes in the memory region that needs to be privatized. Example: int c[3][4]; pragma omp parallel reduction(+: c[1:1][1:2]) { } This relands commit r316229 that I reverted in r316235 because it failed on some bots. During investigation I found that this was because Clang and GCC evaluate the two arguments to emplace_back() in ReductionCodeGen::emitSharedLValue() in a different order, hence leading to a different order of generated instructions in the final LLVM IR. Fix this by passing in the arguments from temporary variables that are evaluated in a defined order. Differential Revision: https://reviews.llvm.org/D39136 llvm-svn: 316362
* CodeGen: Fix invalid bitcast in partial initialization of automatic arrary ↵Yaxun Liu2017-10-231-1/+1
| | | | | | | | variable Differential Revision: https://reviews.llvm.org/D39184 llvm-svn: 316353
* Revert "[OpenMP] Avoid VLAs for some reductions on array sections"Jonas Hahnfeld2017-10-202-9/+8
| | | | | | | | | | This breaks at least two buildbots: http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/1175 http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/10478 This reverts commit r316229 during local investigation. llvm-svn: 316235
* [OpenMP] Avoid VLAs for some reductions on array sectionsJonas Hahnfeld2017-10-202-8/+9
| | | | | | | | | | | | | | | | | | | | | | | In some cases the compiler can deduce the length of an array section as constants. With this information, VLAs can be avoided in place of a constant sized array or even a scalar value if the length is 1. Example: int a[4], b[2]; pragma omp parallel reduction(+: a[1:2], b[1:1]) { } For chained array sections, this optimization is restricted to cases where all array sections except the last have a constant length 1. This trivially guarantees that there are no holes in the memory region that needs to be privatized. Example: int c[3][4]; pragma omp parallel reduction(+: c[1:1][1:2]) { } Differential Revision: https://reviews.llvm.org/D39136 llvm-svn: 316229
* [CodeGen] Fix generation of TBAA info for array-to-pointer conversionsIvan A. Kosarev2017-10-201-2/+8
| | | | | | | | | | Resolves: Fatal error: Offset not zero at the point of scalar access. http://llvm.org/PR34992 Differential Revision: https://reviews.llvm.org/D39083 llvm-svn: 316211
* [CGExprScalar] Add missing types in function GetIntrinsicGuozhi Wei2017-10-191-2/+11
| | | | | | | | In function GetIntrinsic, not all types are covered. Types double and long long are missed, type long is wrongly treated same as int, it should be same as long long. These problems cause compiler crashes when compiling code in PR31161. This patch fixed the problem. Differential Revision: https://reviews.llvm.org/D38820 llvm-svn: 316179
* [AMDGPU] Fix bug in enqueued block codegen due to an extra lineYaxun Liu2017-10-191-1/+0
| | | | llvm-svn: 316165
* [OPENMP] Fix capturing of boolean variables in debug mode.Alexey Bataev2017-10-171-4/+5
| | | | | | | | If the variables is boolean and we generating inner function with real types, the codegen may crash because of not loading boolean value from memory. llvm-svn: 316011
* CodeGen: Fix invalid bitcasts for atomic builtinsYaxun Liu2017-10-171-2/+4
| | | | | | | | | | | | | Currently clang assumes the temporary variables emitted during codegen of atomic builtins have address space 0, which is not true for target triple amdgcn---amdgiz and causes invalid bitcasts. This patch fixes that. Differential Revision: https://reviews.llvm.org/D38966 llvm-svn: 316000
* [CodeGen] Refine generation of TBAA info for bit-field lvaluesIvan A. Kosarev2017-10-171-63/+51
| | | | | | | | | | | | | | | | | The main change is that now we generate TBAA info before constructing the resulting lvalue instead of constructing lvalue with some default TBAA info and fixing it as necessary afterwards. We also keep the TBAA info close to lvalue base info, which is supposed to simplify their future merging. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38947 llvm-svn: 315989
* [CodeGen] Pass TBAA info along with lvalue base info everywhereIvan A. Kosarev2017-10-175-55/+43
| | | | | | | | | | | | | | This patch addresses the rest of the cases where we pass lvalue base info, but do not provide corresponding TBAA info. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to make reviewing easier. Differential Revision: https://reviews.llvm.org/D38945 llvm-svn: 315986
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-177-42/+91
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
* [Coverage] Discard deferred region in closing if-elseVedant Kumar2017-10-171-7/+23
| | | | | | | | | | | | | | | | A trailing deferred region isn't necessary in a function that ends with this pattern: ... else { ... return; } Special-case this pattern so that the closing curly brace of the function isn't marked as uncovered. This issue came up in PR34962. llvm-svn: 315982
* [Coverage] Explicitly mark the l.h.s of && and || (fixes PR33465)Vedant Kumar2017-10-171-4/+6
| | | | | | | | | | This makes it possible to view sub-line region counts for the l.h.s of && and || expressions in coverage reports. It also fixes PR33465, which shows an example of incorrect coverage output for an assignment statement containing '||'. llvm-svn: 315979
* [Bitfield] Add an option to access bitfield in a fine-grained manner.Wei Mi2017-10-161-2/+35
| | | | | | | | Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default. Differential revision: https://reviews.llvm.org/D36562 llvm-svn: 315915
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-1512-63/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* Fix build failure on android due to missing std::to_string()Yaxun Liu2017-10-141-1/+2
| | | | llvm-svn: 315805
* [OpenCL] Emit enqueued block as kernelYaxun Liu2017-10-148-46/+262
| | | | | | | | | | | | | | | | | In OpenCL the kernel function and non-kernel function has different calling conventions. For certain targets they have different argument ABIs. Also kernels have special function attributes and metadata for runtime to launch them. The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such, the block invoke function should be emitted as kernel with proper calling convention and argument ABI. This patch emits enqueued block as kernel. If a block is both called directly and passed to enqueue_kernel, separate functions will be generated. Differential Revision: https://reviews.llvm.org/D38134 llvm-svn: 315804
* [ubsan] Don't emit function signatures for non-static member functionsVedant Kumar2017-10-141-2/+10
| | | | | | | | | | | | | | | | | | The function sanitizer only checks indirect calls through function pointers. This excludes all non-static member functions (constructor calls, calls through thunks, etc. all use a separate code path). Don't emit function signatures for functions that won't be checked. Apart from cutting down on code size, this should fix a regression on Linux caused by r313096. For context, see the mailing list discussion: r313096 - [ubsan] Function Sanitizer: Don't require writable text segments Testing: check-clang, check-ubsan Differential Revision: https://reviews.llvm.org/D38913 llvm-svn: 315786
* Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along ↵Ivan A. Kosarev2017-10-137-84/+36
| | | | | | | | | | with LValue base info", r315731. With this change we fail on the clang-x86_64-linux-selfhost-modules builder. Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315739
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-137-36/+84
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315731
* [CodeGen] emitOMPArraySectionBase() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-5/+10
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38795 llvm-svn: 315715
* [CodeGen] getNaturalTypeAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-134-20/+25
| | | | | | | | | | base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38794 llvm-svn: 315708
* [SEH] Use the SEH personality on frontend-outlined funcletsReid Kleckner2017-10-131-1/+6
| | | | | | | | This allows __try inside __finally to work. Fixes PR34939 llvm-svn: 315707
* [CodeGen] EmitLoadOfReference() to generate TBAA info along with LValue base ↵Ivan A. Kosarev2017-10-132-5/+10
| | | | | | | | | | info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38793 llvm-svn: 315705
* [CodeGen] EmitLoadOfPointer() to generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-132-5/+10
| | | | | | | | This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38791 llvm-svn: 315704
* [CodeGen] EmitCXXMemberDataPointerAddress() to generate TBAA info along with ↵Ivan A. Kosarev2017-10-133-5/+10
| | | | | | | | | | LValue base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38788 llvm-svn: 315702
* Fix an unused-variable warning.Haojian Wu2017-10-131-1/+1
| | | | llvm-svn: 315689
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-133-45/+144
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* [MS] Don't bail on replacing dllimport vbase dtors with base dtorsReid Kleckner2017-10-133-20/+17
| | | | | | | | | | | | | | | | | | | | | Fix PR32990 by effectively reverting r283063 and solving it a different way. We want to limit the hack to not replace equivalent available_externally dtors specifically to libc++, which uses always_inline. It seems certain versions of libc++ do not provide all the symbols that an explicit template instantiation is expected to provide. If we get to the code that forms a real alias, only *then* check if this is available_externally, and do that by asking a better question, which is "is this a declaration for the linker?", because *that's* what means we can't form an alias to it. As a follow-on simplification, remove the InEveryTU parameter. Its last use guarded this code for forming aliases, but we should never form aliases to declarations, regardless of what we know about every TU. llvm-svn: 315656
* Handle/assert on DK_RemarkAdam Nemet2017-10-121-0/+4
| | | | | | | We don't generate remarks during inline assembly parsing so no need to handle these for now. llvm-svn: 315643
* [CUDA] Added __hmma_m16n16k16_* builtins to support mma instructions on sm_70Artem Belevich2017-10-121-0/+198
| | | | | | Differential Revision: https://reviews.llvm.org/D38742 llvm-svn: 315624
* [OPENMP] Fix PR34927: Emit initializer for reduction array with declareAlexey Bataev2017-10-121-3/+8
| | | | | | | | | reduction. If the reduction is an array or an array section and reduction operation is declare reduction without initializer, it may lead to crash. llvm-svn: 315611
* [OPENMP] Fix PR34926: Fix handling of the array sections passed asAlexey Bataev2017-10-121-6/+1
| | | | | | | | | function params. Codegen could crash if the array section base expression is the function parameter. llvm-svn: 315586
* [OPENMP] Fix PR34925: Fix getting thread_id lvalue for inlined regionsAlexey Bataev2017-10-121-0/+7
| | | | | | | | | | | in C. If we try to get the lvalue for thread_id variables in inlined regions, we did not use the correct version of function. Fixed this bug by adding overrided version of the function getThreadIDVariableLValue for inlined regions. llvm-svn: 315578
* [CodeGen] Generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-124-27/+48
| | | | | | | | | | | | | | | | | | This patch enables explicit generation of TBAA information in all cases where LValue base info is propagated or constructed in non-trivial ways. Eventually, we will consider each of these cases to make sure the TBAA information is correct and not too conservative. For now, we just fall back to generating TBAA info from the access type. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38733 llvm-svn: 315575
* Revert "[ADT] Make Twine's copy constructor private."Zachary Turner2017-10-112-36/+41
| | | | | | | | | | This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5. This is failing due to some code that isn't built on MSVC so I didn't catch. Not immediately obvious how to fix this at first glance, so I'm reverting for now. llvm-svn: 315536
* [ADT] Make Twine's copy constructor private.Zachary Turner2017-10-112-41/+36
| | | | | | | | | | | | | | | | | There's a lot of misuse of Twine scattered around LLVM. This ranges in severity from benign (returning a Twine from a function by value that is just a string literal) to pretty sketchy (storing a Twine by value in a class). While there are some uses for copying Twines, most of the very compelling ones are confined to the Twine class implementation itself, and other uses are either dubious or easily worked around. This patch makes Twine's copy constructor private, and fixes up all callsites. Differential Revision: https://reviews.llvm.org/D38767 llvm-svn: 315530
* [X86] Add support for 'amdfam17h' to __builtin_cpu_is to match gcc.Craig Topper2017-10-111-0/+2
| | | | | | The compiler-rt implementation already supported it, it just wasn't exposed. llvm-svn: 315517
OpenPOWER on IntegriCloud