summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [OPENMP] Remove extra if, NFC.Alexey Bataev2017-10-111-1/+1
| | | | llvm-svn: 315467
* [OPENMP] Fix PR34916: Crash on mixing taskloop|tasks directives.Alexey Bataev2017-10-112-3/+18
| | | | | | | | If both taskloop and task directives are used at the same time in one program, we may ran into the situation when the particular type for task directive is reused for taskloop directives. Patch fixes this problem. llvm-svn: 315464
* Include getting generated struct offsets in CodegenABITypesAdrian Prantl2017-10-101-0/+7
| | | | | | | | | | | | | | | | | | | | This change adds a new function, CodeGen::getFieldNumber, that enables a user of clang's code generation to get the field number in a generated LLVM IR struct that corresponds to a particular field in a C struct. It is important to expose this information in Clang's code generation interface because there is no reasonable way for users of Clang's code generation to get this information. In particular: LLVM struct types do not include field names. Clang adds a non-trivial amount of logic to the code generation of LLVM IR types for structs, in particular to handle padding and bit fields. Patch by Michael Ferguson! Differential Revision: https://reviews.llvm.org/D38473 llvm-svn: 315392
* [CGExprScalar] In EmitCompare trunc the result if it has different type as ↵Guozhi Wei2017-10-101-0/+10
| | | | | | | | | | | | | | | | E->getType() Usually compare expression should return i1 type, so EmitScalarConversion is called before return return EmitScalarConversion(Result, CGF.getContext().BoolTy, E->getType(), E->getExprLoc()); But when ppc intrinsic is called to compare vectors, the ppc intrinsic can return i32 even E->getType() is BoolTy, in this case EmitScalarConversion does nothing, an i32 type result is returned and causes crash later. This patch detects this case and truncates the result before return. Differential Revision: https://reviews.llvm.org/D38656 llvm-svn: 315358
* [OPENMP] Add default codegen|tests for 'target parallel for[ simd]'Alexey Bataev2017-10-101-1/+8
| | | | | | | | | constructs. Added default codegen for 'target parallel for' construct + tests for default codegen of 'target parallel for[ simd]' constructs. llvm-svn: 315315
* [CodeGen] Do not construct complete LValue base info in trivial casesIvan A. Kosarev2017-10-106-71/+74
| | | | | | | | | | | | | Besides obvious code simplification, avoiding explicit creation of LValueBaseInfo objects makes it easier to make TBAA information to be part of such objects. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38695 llvm-svn: 315289
* AMDGPU: Add read_exec_lo/hi builtinsMatt Arsenault2017-10-091-0/+9
| | | | llvm-svn: 315238
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-2/+0
| | | | llvm-svn: 315196
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-082-2/+0
| | | | llvm-svn: 315185
* OpenCL: Assume functions are convergentMatt Arsenault2017-10-061-5/+8
| | | | | | | | | This was done for CUDA functions in r261779, and for the same reason this also needs to be done for OpenCL. An arbitrary function could have a barrier() call in it, which in turn requires the calling function to be convergent. llvm-svn: 315094
* Split X86::BI__builtin_cpu_init handling into own function[NFC]Erich Keane2017-10-062-7/+10
| | | | | | | | The Cpu Init functionality is required for the target attribute, so this patch simply splits it out into its own function, exactly like CpuIs and CpuSupports. llvm-svn: 315075
* [OPENMP] Capture references to global variables.Alexey Bataev2017-10-061-2/+6
| | | | | | | | In C++11 variable to global variables are considered as constant expressions and these variables are not captured in the outlined regions. Patch allows capturing of such variables in the OpenMP regions. llvm-svn: 315074
OpenPOWER on IntegriCloud