summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP] Replace calls of getAssociatedStmt().Alexey Bataev2018-01-121-0/+1
| | | | | | | | | | | | | getAssociatedStmt() returns the outermost captured statement for the OpenMP directive. It may return incorrect region in case of combined constructs. Reworked the code to reduce the number of calls of getAssociatedStmt() and used getInnermostCapturedStmt() and getCapturedStmt() functions instead. In case of firstprivate variables it may lead to an extra allocas generation for private copies even if the variable is passed by value into outlined function and could be used directly as private copy. llvm-svn: 322393
* Implement Attribute Target MultiVersioningErich Keane2018-01-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* [OpenMP] Initial implementation of code generation for pragma 'target teams ↵Carlo Bertolli2018-01-031-0/+4
| | | | | | | | | | distribute parallel for' on host https://reviews.llvm.org/D41709 This patch includes code generation and testing for offloading when target device is host. llvm-svn: 321759
* [WinEH] Allow for multiple terminatepadsReid Kleckner2018-01-021-0/+8
| | | | | | | | | Fixes verifier errors with Windows EH and OpenMP, which injects a terminate scope around parallel blocks. Fixes PR35778 llvm-svn: 321676
* [OPENMP] Support for -fopenmp-simd option with compilation of simd loopsAlexey Bataev2017-12-291-0/+3
| | | | | | | | | only. Added support for -fopenmp-simd option that allows compilation of simd-based constructs without emission of OpenMP runtime calls. llvm-svn: 321560
* -fsanitize=vptr warnings on bad static types in dynamic_cast and typeidStephan Bergmann2017-12-281-1/+4
| | | | | | | | | | ...when such an operation is done on an object during con-/destruction. This is the cfe part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40295 llvm-svn: 321519
* [OPENMP] Support for `depend` clauses on `target data update`.Alexey Bataev2017-12-271-0/+14
| | | | | | Added codegen for `depend` clauses on `target data update` directives. llvm-svn: 321493
* [AArch64] Enable fp16 data type for the Builtin for AArch64 only.Abderrazek Zaafrani2017-12-211-3/+6
| | | | | | Differential Revision: https:://reviews.llvm.org/D41360 llvm-svn: 321301
* [ubsan] Diagnose noreturn functions which returnVedant Kumar2017-12-211-4/+12
| | | | | | | | | | | | | | | | | | Diagnose 'unreachable' UB when a noreturn function returns. 1. Insert a check at the end of functions marked noreturn. 2. A decl may be marked noreturn in the caller TU, but not marked in the TU where it's defined. To diagnose this scenario, strip away the noreturn attribute on the callee and insert check after calls to it. Testing: check-clang, check-ubsan, check-ubsan-minimal, D40700 rdar://33660464 Differential Revision: https://reviews.llvm.org/D40698 llvm-svn: 321231
* [Hexagon] Intrinsic support for V62 and V65Krzysztof Parzyszek2017-12-131-0/+1
| | | | llvm-svn: 320609
* [OPENMP] Initial codegen for `target teams distribute simd` directive.Alexey Bataev2017-12-131-0/+4
| | | | | | | Host + generic device codegen for `target teams distribute simd` directive. llvm-svn: 320608
* [OPENMP] Initial codegen for `target teams distribute` directive.Alexey Bataev2017-12-081-3/+9
| | | | | | Host + default devices codegen for `target teams distribute` directive. llvm-svn: 320149
* [ubsan] Use pass_object_size info in bounds checksVedant Kumar2017-12-081-0/+5
| | | | | | | | | Teach UBSan's bounds check to opportunistically use pass_object_size information to check array accesses. rdar://33272922 llvm-svn: 320128
* [XRay][clang] Introduce -fxray-always-emit-customeventsDean Michael Berris2017-11-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-emit-customevents flag instructs clang to always emit the LLVM IR for calls to the `__xray_customevent(...)` built-in function. The default behaviour currently respects whether the function has an `[[clang::xray_never_instrument]]` attribute, and thus not lower the appropriate IR code for the custom event built-in. This change allows users calling through to the `__xray_customevent(...)` built-in to always see those calls lowered to the corresponding LLVM IR to lay down instrumentation points for these custom event calls. Using this flag enables us to emit even just the user-provided custom events even while never instrumenting the start/end of the function where they appear. This is useful in cases where "phase markers" using __xray_customevent(...) can have very few instructions, must never be instrumented when entered/exited. Reviewers: rnk, dblaikie, kpw Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40601 llvm-svn: 319388
* [OPENMP] Codegen for `target simd` construct.Alexey Bataev2017-11-171-6/+10
| | | | | | Added codegen support for `target simd` directive. llvm-svn: 318536
* [OPENMP] Add support for cancelling inside target parallel forAlexey Bataev2017-11-161-13/+13
| | | | | | | | directive. Added missed support for cancelling of target parallel for construct. llvm-svn: 318434
* Switch -mcount and -finstrument-functions to emit EnterExitInstrumenter ↵Hans Wennborg2017-11-141-5/+0
| | | | | | | | | | | | | | | | attributes This updates -mcount to use the new attribute names (LLVM r318195), and switches over -finstrument-functions to also use these attributes rather than inserting instrumentation in the frontend. It also adds a new flag, -finstrument-functions-after-inlining, which makes the cygprofile instrumentation get inserted after inlining rather than before. Differential Revision: https://reviews.llvm.org/D39331 llvm-svn: 318199
* [coroutines] Promote cleanup.dest.slot allocas to registers to avoid storing ↵Gor Nishanov2017-11-111-17/+21
| | | | | | | | | | | | | | | | | | | | | | it in the coroutine frame Summary: We don't want to store cleanup dest slot saved into the coroutine frame (as some of the cleanup code may access them after coroutine frame destroyed). This is an alternative to https://reviews.llvm.org/D37093 It is possible to do this for all functions, but, cursory check showed that in -O0, we get slightly longer function (by 1-3 instructions), thus, we are only limiting cleanup.dest.slot elimination to coroutines. Reviewers: rjmccall, hfinkel, eric_niebler Reviewed By: eric_niebler Subscribers: EricWF, cfe-commits Differential Revision: https://reviews.llvm.org/D39768 llvm-svn: 317981
* Remove declaration of EmitMCountInstrumentation(). NFCHans Wennborg2017-11-101-3/+0
| | | | | | The definition was removed in r280355. llvm-svn: 317944
* [OPENMP] Codegen for `#pragma omp target parallel for simd`.Alexey Bataev2017-11-091-0/+4
| | | | | | Added codegen for `#pragma omp target parallel for simd` and clauses. llvm-svn: 317813
* [OPENMP] Codegen for `#pragma omp target parallel for`.Alexey Bataev2017-11-081-0/+4
| | | | llvm-svn: 317719
* [CodeGen] Propagate may-alias'ness of lvalues with TBAA infoIvan A. Kosarev2017-10-311-7/+4
| | | | | | | | | | | | | This patch fixes various places in clang to propagate may-alias TBAA access descriptors during construction of lvalues, thus eliminating the need for the LValueBaseInfo::MayAlias flag. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D39008 llvm-svn: 316988
* [CodeGen] Generate TBAA info for reference loadsIvan A. Kosarev2017-10-301-4/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D39177 llvm-svn: 316896
* [CodeGen] Pass TBAA info along with lvalue base info everywhereIvan A. Kosarev2017-10-171-14/+0
| | | | | | | | | | | | | | 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-171-3/+6
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
* [OpenCL] Emit enqueued block as kernelYaxun Liu2017-10-141-3/+13
| | | | | | | | | | | | | | | | | 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
* Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along ↵Ivan A. Kosarev2017-10-131-6/+3
| | | | | | | | | | 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-131-3/+6
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315731
* [CodeGen] getNaturalTypeAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-0/+1
| | | | | | | | | | base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38794 llvm-svn: 315708
* [CodeGen] EmitLoadOfReference() to generate TBAA info along with LValue base ↵Ivan A. Kosarev2017-10-131-1/+2
| | | | | | | | | | 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-131-1/+2
| | | | | | | | 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-131-1/+2
| | | | | | | | | | LValue base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38788 llvm-svn: 315702
* [CodeGen] Generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-121-5/+5
| | | | | | | | | | | | | | | | | | 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
* [CodeGen] Do not construct complete LValue base info in trivial casesIvan A. Kosarev2017-10-101-8/+32
| | | | | | | | | | | | | 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
* Split X86::BI__builtin_cpu_init handling into own function[NFC]Erich Keane2017-10-061-0/+1
| | | | | | | | 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
* Refine generation of TBAA information in clangIvan A. Kosarev2017-10-061-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is an attempt to clarify and simplify generation and propagation of TBAA information. The idea is to pack all values that describe a memory access, namely, base type, access type and offset, into a single structure. This is supposed to make further changes, such as adding support for unions and array members, easier to prepare and review. DecorateInstructionWithTBAA() is no more responsible for converting types to tags. These implicit conversions not only complicate reading the code, but also suggest assigning scalar access tags while we generally prefer full-size struct-path tags. TBAAPathTag is replaced with TBAAAccessInfo; the latter is now the type of the keys of the cache map that translates access descriptors to metadata nodes. Fixed a bug with writing to a wrong map in getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()). We now check for valid base access types every time we dereference a field. The original code only checks the top-level base type. See isValidBaseType() / isTBAAPathStruct() calls. Some entities have been renamed to sound more adequate and less confusing/misleading in presence of path-aware TBAA information. Now we do not lookup twice for the same cache entry in getAccessTagInfo(). Refined relevant comments and descriptions. Differential Revision: https://reviews.llvm.org/D37826 llvm-svn: 315048
* [CodeGen] Emit a helper function for __builtin_os_log_format to reduceAkira Hatanaka2017-10-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | code size. Currently clang expands a call to __builtin_os_log_format into a long sequence of instructions at the call site, causing code size to increase in some cases. This commit attempts to reduce code size by emitting a helper function that can be shared by calls to __builtin_os_log_format with similar formats and arguments. The helper function has linkonce_odr linkage to enable the linker to merge identical functions across translation units. Attribute 'noinline' is attached to the helper function at -Oz so that the inliner doesn't inline functions that can potentially be merged. This commit also fixes a bug where the generated IR writes past the end of the buffer when "%m" is the last specifier appearing in the format string passed to __builtin_os_log_format. Original patch by Duncan Exon Smith. rdar://problem/34065973 rdar://problem/34196543 Differential Revision: https://reviews.llvm.org/D38606 llvm-svn: 315045
* Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"Ivan A. Kosarev2017-10-051-18/+4
| | | | | | | | D37826 has been mistakenly committed where it should be the patch from D38503. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314978
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314977
* [CodeGen] Introduce generic TBAA access descriptorsIvan A. Kosarev2017-10-031-6/+3
| | | | | | | | | | | | | With this patch we implement a concept of TBAA access descriptors that are capable of representing both scalar and struct-path accesses in a generic way. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38456 llvm-svn: 314780
* [ubsan] Add helpers to decide when null/vptr checks are required. NFC.Vedant Kumar2017-10-031-0/+6
| | | | llvm-svn: 314750
* [CodeGen] Do not refer to complete TBAA info where we actually deal with ↵Ivan A. Kosarev2017-10-021-5/+5
| | | | | | | | | | | | | | just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 llvm-svn: 314657
* [OPENMP] Generate implicit map|firstprivate clauses for target-basedAlexey Bataev2017-09-261-0/+3
| | | | | | | | | | directives. If the variable is used in the target-based region but is not found in any private|mapping clause, then generate implicit firstprivate|map clauses for these implicitly mapped variables. llvm-svn: 314205
* [CodeGen][ObjC] Build the global block structure before emitting theAkira Hatanaka2017-09-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | body of global block invoke functions. This commit fixes an infinite loop in IRGen that occurs when compiling the following code: void FUNC2() { static void (^const block1)(int) = ^(int a){ if (a--) block1(a); }; } This is how IRGen gets stuck in the infinite loop: 1. GenerateBlockFunction is called to emit the body of "block1". 2. GetAddrOfGlobalBlock is called to get the address of "block1". The function calls getAddrOfGlobalBlockIfEmitted to check whether the global block has been emitted. If it hasn't been emitted, it then tries to emit the body of the block function by calling GenerateBlockFunction, which goes back to step 1. This commit prevents the inifinite loop by building the global block in GenerateBlockFunction before emitting the body of the block function. rdar://problem/34541684 Differential Revision: https://reviews.llvm.org/D38118 llvm-svn: 314029
* [OPENMP] Handle re-declaration of captured variables in CodeGen.Alexey Bataev2017-09-221-3/+3
| | | | | | | | | If the captured variable has re-declaration we may end up with the situation where the captured variable is the re-declaration while the referenced variable is the canonical declaration (or vice versa). In this case we may generate wrong code. Patch fixes this situation. llvm-svn: 313995
* [ubsan] Function Sanitizer: Don't require writable text segmentsVedant Kumar2017-09-131-0/+9
| | | | | | | | | | | | | | | | | | This change will make it possible to use -fsanitize=function on Darwin and possibly on other platforms. It fixes an issue with the way RTTI is stored into function prologue data. On Darwin, addresses stored in prologue data can't require run-time fixups and must be PC-relative. Run-time fixups are undesirable because they necessitate writable text segments, which can lead to security issues. And absolute addresses are undesirable because they break PIE mode. The fix is to create a private global which points to the RTTI, and then to encode a PC-relative reference to the global into prologue data. Differential Revision: https://reviews.llvm.org/D37597 llvm-svn: 313096
* Updated two annotations for Store.h and CodeGenFunction.h.Krasimir Georgiev2017-09-081-2/+1
| | | | | | | | | | | | | | | | | | Summary: 1.Updated annotations for include/clang/StaticAnalyzer/Core/PathSensitive/Store.h, which belong to the old version of clang. 2.Delete annotations for CodeGenFunction::getEvaluationKind() in clang/lib/CodeGen/CodeGenFunction.h, which belong to the old version of clang. Reviewers: bkramer, krasimir, klimek Reviewed By: bkramer Subscribers: MTC Differential Revision: https://reviews.llvm.org/D36330 Contributed by @MTC! llvm-svn: 312790
* Debug info: Fixed faulty debug locations for attributed statementsKarl-Johan Karlsson2017-09-061-1/+1
| | | | | | | | | | | | | | | | | Summary: As the attributed statements are considered simple statements no stoppoint was generated before emitting attributed do/while/for/range- statement. This lead to faulty debug locations. Reviewers: echristo, aaron.ballman, dblaikie Reviewed By: dblaikie Subscribers: bjope, aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D37428 llvm-svn: 312623
* [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with Erich Keane2017-09-011-0/+4
| | | | | | | | | | | | | | | | | | | | "target" implementation A small set of refactors that'll make it easier for me to implement 'target' support. First, extract the CPUSupports functionality into its own function. THis has the advantage of not wasting time in this builtin to deal with arguments. Second, pulls both CPUSupports and CPUIs implementation into a member-function, so that it can be called from the resolver generation that I'm working on. Third, creates an overload that takes simply the feature/cpu name (rather than extracting it from a callexpr), since that info isn't available later. Note that despite how the 'diff' looks, the EmitX86CPUSupports function simply takes the implementation out of the 'switch'. llvm-svn: 312355
* [IRGen] Evaluate constant static variables referenced through memberAlex Lorenz2017-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static variables that were referenced using a member expression were always emitted using lvalue loads. The old behaviour introduced an inconsistency between regular uses of static variables and member expressions uses. For example, the following program compiled and linked successfully: struct Foo { constexpr static const char *name = "foo"; }; int main() { return Foo::name[0] == 'f'; } but this program failed to link because "Foo::name" wasn't found: struct Foo { constexpr static const char *name = "foo"; }; int main() { Foo f; return f.name[0] == 'f'; } This commit ensures that constant static variables referenced through member expressions are emitted in the same way as ordinary static variable references. rdar://33942261 Differential Revision: https://reviews.llvm.org/D36876 llvm-svn: 311772
OpenPOWER on IntegriCloud