maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/CodeGen/CodeGenModule.cpp

4687 lines
176 KiB
C++
Raw Normal View History

Reorganize codegen files. llvm-svn: 39504
2007-05-28 09:07:47 +08:00
//===--- CodeGenModule.cpp - Emit LLVM Code from ASTs for a Module --------===//
//
// The LLVM Compiler Infrastructure
//
Don't attribute in file headers anymore. See llvmdev for the discussion of this change. llvm-svn: 45410
2007-12-30 03:59:25 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Reorganize codegen files. llvm-svn: 39504
2007-05-28 09:07:47 +08:00
//
//===----------------------------------------------------------------------===//
//
// This coordinates the per-module state used while generating code.
//
//===----------------------------------------------------------------------===//
#include "CodeGenModule.h"
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
#include "CGBlocks.h"
CUDA: IR generation support for kernel call expressions llvm-svn: 141300
2011-10-07 02:29:37 +08:00
#include "CGCUDARuntime.h"
Teach IR generation to return 'this' from constructors and destructors under the ARM ABI. llvm-svn: 112588
2010-08-31 15:33:07 +08:00
#include "CGCXXABI.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "CGCall.h"
#include "CGDebugInfo.h"
Change ObjCRuntime GenerateProtocol[Ref] methods to take ObjCProtocolDecl directly. Implement CodeGen support for forward protocol decls (no-ops are so nice to implement). Also moved CGObjCRuntime.h out of CodeGenModule.h llvm-svn: 54709
2008-08-13 08:59:25 +08:00
#include "CGObjCRuntime.h"
OpenCL: introduce support for function scope __local variables llvm-svn: 140068
2011-09-20 05:14:35 +08:00
#include "CGOpenCLRuntime.h"
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 18:08:46 +08:00
#include "CGOpenMPRuntime.h"
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
2016-02-08 23:59:20 +08:00
#include "CGOpenMPRuntimeNVPTX.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "CodeGenFunction.h"
CodeGen: Initial instrumentation based PGO implementation llvm-svn: 198640
2014-01-07 06:27:43 +08:00
#include "CodeGenPGO.h"
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
#include "ConstantEmitter.h"
[cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.py Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
2015-01-14 19:29:14 +08:00
#include "CoverageMappingGen.h"
Generalize target weirdness handling having proper layering in mind: 1. Add helper class for sema checks for target attributes 2. Add helper class for codegen of target attributes As a proof-of-concept - implement msp430's 'interrupt' attribute. llvm-svn: 93118
2010-01-10 20:58:08 +08:00
#include "TargetInfo.h"
Refactor CodeGenTypes out to CodeGenModule so it can be used for functions and globals. llvm-svn: 39661
2007-06-16 08:16:26 +08:00
#include "clang/AST/ASTContext.h"
Introduce CodeGenModule::GetTargetTypeStoreSize() to calculate the store size of LLVM types in character units. llvm-svn: 94542
2010-01-26 21:48:07 +08:00
#include "clang/AST/CharUnits.h"
LinkageSpecDecl is c++ specific, move it to DeclCXX llvm-svn: 58704
2008-11-05 00:51:42 +08:00
#include "clang/AST/DeclCXX.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/AST/DeclObjC.h"
Instantiations subject to an explicit template instantiation declaration have default visibility even under -fvisibility=hidden. Fixes <rdar://problem/8109763>. llvm-svn: 106440
2010-06-22 02:41:26 +08:00
#include "clang/AST/DeclTemplate.h"
Move name mangling support from CodeGen to AST. In the process, perform a number of refactorings: - Move MiscNameMangler member functions to MangleContext - Remove GlobalDecl dependency from MangleContext - Make MangleContext abstract and move Itanium/Microsoft functionality to their own classes/files - Implement ASTContext::createMangleContext and have CodeGen use it No (intended) functionality change. llvm-svn: 123386
2011-01-14 02:57:25 +08:00
#include "clang/AST/Mangle.h"
Have ASTRecordLayout keep track of the key function, in preparation of fixing a synthetic ctor/dtor bug. llvm-svn: 90168
2009-12-01 07:41:22 +08:00
#include "clang/AST/RecordLayout.h"
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
#include "clang/AST/RecursiveASTVisitor.h"
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
#include "clang/Basic/Builtins.h"
Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h. Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
2013-02-09 06:30:41 +08:00
#include "clang/Basic/CharInfo.h"
warn about unhandled initializers instead of crashing on them. llvm-svn: 44510
2007-12-02 15:19:18 +08:00
#include "clang/Basic/Diagnostic.h"
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
#include "clang/Basic/Module.h"
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
#include "clang/Basic/SourceManager.h"
Build enough support for aggregates to be able to compile this: void test(int A, _Complex float Y) { _Complex float X; X = X; } llvm-svn: 39669
2007-06-23 02:48:09 +08:00
#include "clang/Basic/TargetInfo.h"
Emit a .ident saying that clang produced this file. Patch by Katya Romanova. llvm-svn: 192832
2013-10-17 03:28:50 +08:00
#include "clang/Basic/Version.h"
Promote ConstantInitBuilder to be a public CodeGen API; it's a generally useful utility for other frontends. NFC. llvm-svn: 296806
2017-03-03 04:04:19 +08:00
#include "clang/CodeGen/ConstantInitBuilder.h"
revert SVN r265702, r265640 Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
2016-04-09 00:52:00 +08:00
#include "clang/Frontend/CodeGenOptions.h"
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
#include "clang/Sema/SemaDiagnostic.h"
Implement __builtin_dwarf_sp_column for i386 (Darwin and not), x86-64 (all), and ARM. Implement __builtin_init_dwarf_reg_size_table for i386 (both) and x86-64 (all). llvm-svn: 97859
2010-03-06 08:35:14 +08:00
#include "llvm/ADT/Triple.h"
CodeGenModule: Always output wchar_size, check LLVM assumptions. Re-commit r303463 now that LLVM is fixed and adjust some lit tests. llvm::TargetLibraryInfo needs to know the size of wchar_t to work on functions like `wcslen`. This patch changes clang to always emit the wchar_size module flag (it would only do so for ARM previously). This also adds an `assert()` to ensure the LLVM defaults based on the target triple are in sync with clang. Differential Revision: https://reviews.llvm.org/D32982 llvm-svn: 303478
2017-05-20 09:29:55 +08:00
#include "llvm/Analysis/TargetLibraryInfo.h"
[Modules] Update to reflect the move of CallSite into the IR library in LLVM r202816. llvm-svn: 202817
2014-03-04 19:02:08 +08:00
#include "llvm/IR/CallSite.h"
Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
2013-01-02 19:45:17 +08:00
#include "llvm/IR/CallingConv.h"
#include "llvm/IR/DataLayout.h"
#include "llvm/IR/Intrinsics.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
CodeGen: Use LLVM's InstrProfReader in -fprofile-instr-use= Update clang to use the InstrProfReader from LLVM to read instrumentation based profile data. This also switches us from the naive text format to the binary format, since that's what's implemented in the reader. llvm-svn: 206658
2014-04-19 05:52:00 +08:00
#include "llvm/ProfileData/InstrProfReader.h"
Move UTF conversion routines from clang/lib/Basic to llvm/lib/Support This is required to use them in TableGen. llvm-svn: 173924
2013-01-30 20:06:08 +08:00
#include "llvm/Support/ConvertUTF.h"
add missing #include llvm-svn: 86368
2009-11-07 17:22:46 +08:00
#include "llvm/Support/ErrorHandling.h"
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
#include "llvm/Support/MD5.h"
Move UTF conversion routines from clang/lib/Basic to llvm/lib/Support This is required to use them in TableGen. llvm-svn: 173924
2013-01-30 20:06:08 +08:00
Reorganize codegen files. llvm-svn: 39504
2007-05-28 09:07:47 +08:00
using namespace clang;
using namespace CodeGen;
[Coverage] Add an option to emit limited coverage info Add an option to emit limited coverage info for unused decls. It's just a cl::opt for now to allow us to experiment quickly. When building llc, this results in an 84% size reduction in the llvm_covmap section, and a similar size reduction in the llvm_prf_names section. In practice I expect the size reduction to be roughly quadratic with the size of the program. The downside is that coverage for headers will no longer be complete. This will make the line/function/region coverage metrics incorrect, since they will be artificially high. One mitigation would be to somehow disable those metrics when using limited-coverage=true. This is related to: llvm.org/PR34533 (make SourceBasedCodeCoverage scale) Differential Revision: https://reviews.llvm.org/D38107 llvm-svn: 314002
2017-09-23 02:23:04 +08:00
static llvm::cl::opt<bool> LimitedCoverage(
Mark all library options as hidden. These command line options are not intended for public use, and often don't even make sense in the context of a particular tool anyway. About 90% of them are already hidden, but when people add new options they forget to hide them, so if you were to make a brand new tool today, link against one of LLVM's libraries, and run tool -help you would get a bunch of junk that doesn't make sense for the tool you're writing. This patch hides these options. The real solution is to not have libraries defining command line options, but that's a much larger effort and not something I'm prepared to take on. Differential Revision: https://reviews.llvm.org/D40674 llvm-svn: 319505
2017-12-01 08:53:10 +08:00
"limited-coverage-experimental", llvm::cl::ZeroOrMore, llvm::cl::Hidden,
[Coverage] Add an option to emit limited coverage info Add an option to emit limited coverage info for unused decls. It's just a cl::opt for now to allow us to experiment quickly. When building llc, this results in an 84% size reduction in the llvm_covmap section, and a similar size reduction in the llvm_prf_names section. In practice I expect the size reduction to be roughly quadratic with the size of the program. The downside is that coverage for headers will no longer be complete. This will make the line/function/region coverage metrics incorrect, since they will be artificially high. One mitigation would be to somehow disable those metrics when using limited-coverage=true. This is related to: llvm.org/PR34533 (make SourceBasedCodeCoverage scale) Differential Revision: https://reviews.llvm.org/D38107 llvm-svn: 314002
2017-09-23 02:23:04 +08:00
llvm::cl::desc("Emit limited coverage mapping information (experimental)"),
llvm::cl::init(false));
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
static const char AnnotationSection[] = "llvm.metadata";
Tidy up CGCXXABI creation 'create' functions conventionally return a pointer, not a reference. Also use an OwningPtr to get replace the delete of a reference member. No functional change. llvm-svn: 198126
2013-12-29 05:58:40 +08:00
static CGCXXABI *createCXXABI(CodeGenModule &CGM) {
Standardize accesses to the TargetInfo in IR-gen. Patch by Stephen Lin! llvm-svn: 179638
2013-04-17 06:48:15 +08:00
switch (CGM.getTarget().getCXXABI().getKind()) {
Add support for AArch64 target. In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
2013-01-31 20:13:10 +08:00
case TargetCXXABI::GenericAArch64:
Move the decision about the kind of CGCXXABI to make inside the family-specific files. llvm-svn: 173530
2013-01-26 07:36:14 +08:00
case TargetCXXABI::GenericARM:
case TargetCXXABI::iOS:
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
case TargetCXXABI::iOS64:
Watch and TV OS: wire up basic ABI choices This sets the mostly expected Darwin default ABI options for these two platforms. Active changes from these defaults for watchOS are in a later patch. llvm-svn: 251708
2015-10-31 00:30:36 +08:00
case TargetCXXABI::WatchOS:
Change representation of member function pointers for MIPS targets Differential Revision: http://reviews.llvm.org/D7148 llvm-svn: 229680
2015-02-18 23:21:35 +08:00
case TargetCXXABI::GenericMIPS:
Move the decision about the kind of CGCXXABI to make inside the family-specific files. llvm-svn: 173530
2013-01-26 07:36:14 +08:00
case TargetCXXABI::GenericItanium:
[WebAssembly] Initial WebAssembly support in clang This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet finalized, and may change. Differential Revision: http://reviews.llvm.org/D12002 llvm-svn: 246814
2015-09-04 06:51:53 +08:00
case TargetCXXABI::WebAssembly:
Tidy up CGCXXABI creation 'create' functions conventionally return a pointer, not a reference. Also use an OwningPtr to get replace the delete of a reference member. No functional change. llvm-svn: 198126
2013-12-29 05:58:40 +08:00
return CreateItaniumCXXABI(CGM);
Move the decision about the kind of CGCXXABI to make inside the family-specific files. llvm-svn: 173530
2013-01-26 07:36:14 +08:00
case TargetCXXABI::Microsoft:
Tidy up CGCXXABI creation 'create' functions conventionally return a pointer, not a reference. Also use an OwningPtr to get replace the delete of a reference member. No functional change. llvm-svn: 198126
2013-12-29 05:58:40 +08:00
return CreateMicrosoftCXXABI(CGM);
Go back to asking CodeGenTypes whether a type is zero-initializable. Make CGT defer to the ABI on all member pointer types. This requires giving CGT a handle to the ABI. It's way easier to make that work if we avoid lazily creating the ABI. Make it so. llvm-svn: 111786
2010-08-23 05:01:12 +08:00
}
llvm_unreachable("invalid C++ ABI kind");
}
Pass HeaderSearchOptions and PreprocessorOptions into CodeGenModule. In order to produce debug info for clang modules CGDebugInfo it needs access to macros passed on the command line and the isysroot. llvm-svn: 241035
2015-06-30 10:26:03 +08:00
CodeGenModule::CodeGenModule(ASTContext &C, const HeaderSearchOptions &HSO,
const PreprocessorOptions &PPO,
const CodeGenOptions &CGO, llvm::Module &M,
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
DiagnosticsEngine &diags,
CoverageSourceInfo *CoverageInfo)
Pass HeaderSearchOptions and PreprocessorOptions into CodeGenModule. In order to produce debug info for clang modules CGDebugInfo it needs access to macros passed on the command line and the isysroot. llvm-svn: 241035
2015-06-30 10:26:03 +08:00
: Context(C), LangOpts(C.getLangOpts()), HeaderSearchOpts(HSO),
PreprocessorOpts(PPO), CodeGenOpts(CGO), TheModule(M), Diags(diags),
LLVM API Change: the Module always owns the DataLayout From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243115
2015-07-25 00:04:29 +08:00
Target(C.getTargetInfo()), ABI(createCXXABI(*this)),
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
VMContext(M.getContext()), Types(*this), VTables(*this),
Re-apply r267784, r267824 and r267830. I have updated the compiler-rt tests. llvm-svn: 267903
2016-04-29 01:09:37 +08:00
SanitizerMD(new SanitizerMetadata(*this)) {
[ubsan] Add support for -fsanitize-blacklist llvm-svn: 172808
2013-01-18 19:30:38 +08:00
simplify a bunch of code to use the well-known LLVM IR types computed by CodeGenModule. llvm-svn: 149943
2012-02-07 08:39:47 +08:00
// Initialize the type cache.
llvm::LLVMContext &LLVMContext = M.getContext();
VoidTy = llvm::Type::getVoidTy(LLVMContext);
Int8Ty = llvm::Type::getInt8Ty(LLVMContext);
Int16Ty = llvm::Type::getInt16Ty(LLVMContext);
Int32Ty = llvm::Type::getInt32Ty(LLVMContext);
Int64Ty = llvm::Type::getInt64Ty(LLVMContext);
FloatTy = llvm::Type::getFloatTy(LLVMContext);
DoubleTy = llvm::Type::getDoubleTy(LLVMContext);
PointerWidthInBits = C.getTargetInfo().getPointerWidth(0);
PointerAlignInBytes =
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
C.toCharUnitsFromBits(C.getTargetInfo().getPointerAlign(0)).getQuantity();
Re-commit [OpenCL] AMDGCN: Fix size_t type There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
2016-08-19 13:17:25 +08:00
SizeSizeInBytes =
C.toCharUnitsFromBits(C.getTargetInfo().getMaxPointerWidth()).getQuantity();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
IntAlignInBytes =
C.toCharUnitsFromBits(C.getTargetInfo().getIntAlign()).getQuantity();
simplify a bunch of code to use the well-known LLVM IR types computed by CodeGenModule. llvm-svn: 149943
2012-02-07 08:39:47 +08:00
IntTy = llvm::IntegerType::get(LLVMContext, C.getTargetInfo().getIntWidth());
Re-commit [OpenCL] AMDGCN: Fix size_t type There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
2016-08-19 13:17:25 +08:00
IntPtrTy = llvm::IntegerType::get(LLVMContext,
C.getTargetInfo().getMaxPointerWidth());
simplify a bunch of code to use the well-known LLVM IR types computed by CodeGenModule. llvm-svn: 149943
2012-02-07 08:39:47 +08:00
Int8PtrTy = Int8Ty->getPointerTo(0);
Int8PtrPtrTy = Int8PtrTy->getPointerTo(0);
CodeGen: Let lifetime intrinsic use alloca address space Differential Revision: https://reviews.llvm.org/D31717 llvm-svn: 300485
2017-04-18 04:03:11 +08:00
AllocaInt8PtrTy = Int8Ty->getPointerTo(
M.getDataLayout().getAllocaAddrSpace());
CodeGen: Cast alloca to expected address space Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language. For example, in C++ the auto variables are in the default address space. Therefore cast alloca to the expected address space when necessary. Differential Revision: https://reviews.llvm.org/D32248 llvm-svn: 303370
2017-05-19 02:51:09 +08:00
ASTAllocaAddressSpace = getTargetCodeGenInfo().getASTAllocaAddressSpace();
simplify a bunch of code to use the well-known LLVM IR types computed by CodeGenModule. llvm-svn: 149943
2012-02-07 08:39:47 +08:00
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
RuntimeCC = getTargetCodeGenInfo().getABIInfo().getRuntimeCC();
Fix invalid calling convention used for libcalls on ARM. ARM ABI specifies that all the libcalls use soft FP ABI (even hard FP binaries). These days clang emits _mulsc3 / _muldc3 calls with default (C) calling convention which would be translated into AAPCS_VFP LLVM calling and thus the result of complex multiplication will be bogus. Introduce a way for a target to specify explicitly calling convention for libcalls. Right now this is temporary correctness fix. Ultimately, we'll end with intrinsic for complex multiplication and all calling convention decisions for libcalls will be put into backend. llvm-svn: 223123
2014-12-03 00:04:58 +08:00
BuiltinCC = getTargetCodeGenInfo().getABIInfo().getBuiltinCC();
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.ObjC1)
OpenCL: introduce support for function scope __local variables llvm-svn: 140068
2011-09-20 05:14:35 +08:00
createObjCRuntime();
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.OpenCL)
OpenCL: introduce support for function scope __local variables llvm-svn: 140068
2011-09-20 05:14:35 +08:00
createOpenCLRuntime();
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 18:08:46 +08:00
if (LangOpts.OpenMP)
createOpenMPRuntime();
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.CUDA)
CUDA: IR generation support for kernel call expressions llvm-svn: 141300
2011-10-07 02:29:37 +08:00
createCUDARuntime();
Added -g command line options to clang for generating source level debug information. This patch currently enables generation of line number debug information (stoppoints) and region begin/end debug information. The new files CGDebugInfo.h and CGDebugInfo.cpp implements the debug info manager class CGDebugInfo. llvm-svn: 50848
2008-05-08 16:54:20 +08:00
enable TBAA when -fthread-sanitizer is given, even with -O0 or -relaxed-aliasing llvm-svn: 155430
2012-04-24 14:57:01 +08:00
// Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even at O0.
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (LangOpts.Sanitize.has(SanitizerKind::Thread) ||
enable TBAA when -fthread-sanitizer is given, even with -O0 or -relaxed-aliasing llvm-svn: 155430
2012-04-24 14:57:01 +08:00
(!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0))
[CodeGen] Collect information about sizes of accesses and access types for TBAA The information about access and type sizes is necessary for producing TBAA metadata in the new size-aware format. With this patch, D39955 and D39956 in place we should be able to change CodeGenTBAA::createScalarTypeNode() and CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new format under the -new-struct-path-tbaa command-line option. For now, this new information remains unused. Differential Revision: https://reviews.llvm.org/D40176 llvm-svn: 319012
2017-11-27 17:39:29 +08:00
TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
getCXXABI().getMangleContext()));
Experimental TBAA support. This enables metadata generation by default, however the TBAA pass in the optimizer is still disabled for now. llvm-svn: 116536
2010-10-15 07:06:10 +08:00
Wire up the -ftest-coverage and -fprofile-arcs flags to .gcno file emission (at compile time) and .gcda emission (at runtime). --coverage enables both. This does not yet add the profile_rt library to the link step if -fprofile-arcs is enabled when linking. llvm-svn: 129956
2011-04-22 07:44:07 +08:00
// If debug info or coverage generation is enabled, create the CGDebugInfo
// object.
Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend. llvm-svn: 259489
2016-02-02 19:06:51 +08:00
if (CodeGenOpts.getDebugInfo() != codegenoptions::NoDebugInfo ||
CodeGenOpts.EmitGcovArcs || CodeGenOpts.EmitGcovNotes)
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
DebugInfo.reset(new CGDebugInfo(*this));
Reorganize CodeGen{Function,Module} to eliminate the unfortunate Block{Function,Module} base class. Minor other refactorings. Fixed a few address-space bugs while I was there. llvm-svn: 125085
2011-02-08 16:22:06 +08:00
Block.GlobalUniqueCount = 0;
Assorted cleanup: - Have CGM precompute a number of commonly-used types - Have CGF copy that during initialization instead of recomputing them - Use TBAA info when initializing a parameter variable - Refactor the scalar ++/-- code llvm-svn: 125562
2011-02-15 17:22:45 +08:00
Unify the ObjC entrypoint caches. llvm-svn: 250918
2015-10-22 02:06:43 +08:00
if (C.getLangOpts().ObjC1)
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
ObjCData.reset(new ObjCEntrypoints());
CodeGen: Initial instrumentation based PGO implementation llvm-svn: 198640
2014-01-07 06:27:43 +08:00
[PGO] Change profile use cc1 option to handle IR level profiles This patch changes cc1 option for PGO profile use from -fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>. -fprofile-instr-use=<path> is now a driver only option. In addition to decouple the cc1 option from the driver level option, this patch also enables IR level profile use. cc1 option handling now reads the profile header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM} -- this is a common enum for -fprofile-instrument={}, for the profile instrumentation), and invoke the pipeline to enable the respective PGO use pass. Reviewers: silvas, davidxl Differential Revision: http://reviews.llvm.org/D17737 llvm-svn: 262515
2016-03-03 04:59:36 +08:00
if (CodeGenOpts.hasProfileClangUse()) {
auto ReaderOrErr = llvm::IndexedInstrProfReader::create(
CodeGenOpts.ProfileInstrumentUsePath);
Reapply^3 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC" Sync up with "(llvm) Use Error in InstrProf and Coverage". llvm-svn: 270021
2016-05-19 11:54:54 +08:00
if (auto E = ReaderOrErr.takeError()) {
CodeGen: Use LLVM's InstrProfReader in -fprofile-instr-use= Update clang to use the InstrProfReader from LLVM to read instrumentation based profile data. This also switches us from the naive text format to the binary format, since that's what's implemented in the reader. llvm-svn: 206658
2014-04-19 05:52:00 +08:00
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
Display profile file name when emitting a file not found diagnostic. When a profile file cannot be opened, we used to display just the error message but not the name of the profile the compiler was trying to open. This will become useful in the next set of patches that introduce GCC-compatible flags to specify profiles. llvm-svn: 240715
2015-06-26 06:56:00 +08:00
"Could not read profile %0: %1");
Reapply^3 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC" Sync up with "(llvm) Use Error in InstrProf and Coverage". llvm-svn: 270021
2016-05-19 11:54:54 +08:00
llvm::handleAllErrors(std::move(E), [&](const llvm::ErrorInfoBase &EI) {
getDiags().Report(DiagID) << CodeGenOpts.ProfileInstrumentUsePath
<< EI.message();
});
Don't crash when passing a non-existent file to -fprofile-instr-use=. Fixes a regression from r229434. llvm-svn: 234141
2015-04-06 12:16:48 +08:00
} else
PGOReader = std::move(ReaderOrErr.get());
CodeGen: Use LLVM's InstrProfReader in -fprofile-instr-use= Update clang to use the InstrProfReader from LLVM to read instrumentation based profile data. This also switches us from the naive text format to the binary format, since that's what's implemented in the reader. llvm-svn: 206658
2014-04-19 05:52:00 +08:00
}
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
// If coverage mapping generation is enabled, create the
// CoverageMappingModuleGen object.
if (CodeGenOpts.CoverageMapping)
CoverageMapping.reset(new CoverageMappingModuleGen(*this, *CoverageInfo));
Add codegen support for ObjC message expressions with the GNU runtime. Patch by David Chisnall! llvm-svn: 47789
2008-03-01 16:45:05 +08:00
}
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
CodeGenModule::~CodeGenModule() {}
Refactored driver logic for CodeGen into LLVMCodeGenWriter. This ASTConsumer layers on top of LLVMCodeGen (another existing ASTConsumer) to emit bitcode files to disk. This layering takes this logic out of clang.cpp and puts it directly into the ASTConsumer interface. The benefit is that now --emit-llvm works with both serialized ASTs and regular source files. llvm-svn: 54364
2008-08-06 02:50:11 +08:00
Created __builtin___NSStringMakeConstantString() builtin, which generates constant Objective-C strings. llvm-svn: 94274
2010-01-23 10:40:42 +08:00
void CodeGenModule::createObjCRuntime() {
Restructure how the driver communicates information about the target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
2012-06-20 14:18:46 +08:00
// This is just isGNUFamily(), but we want to force implementors of
// new ABIs to decide how best to do this.
switch (LangOpts.ObjCRuntime.getKind()) {
Rename the GCC Objective-C runtime to gcc from gnu-fragile and the GNUstep runtime to gnustep from gnu. Fix EH for the GCC runtime. llvm-svn: 159684
2012-07-04 04:49:52 +08:00
case ObjCRuntime::GNUstep:
case ObjCRuntime::GCC:
Add the ObjFW runtime. Patch by Jonathan Schleifer! llvm-svn: 160102
2012-07-12 10:07:58 +08:00
case ObjCRuntime::ObjFW:
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
ObjCRuntime.reset(CreateGNUObjCRuntime(*this));
Restructure how the driver communicates information about the target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
2012-06-20 14:18:46 +08:00
return;
case ObjCRuntime::FragileMacOSX:
case ObjCRuntime::MacOSX:
case ObjCRuntime::iOS:
Watch and TV OS: wire up basic ABI choices This sets the mostly expected Darwin default ABI options for these two platforms. Active changes from these defaults for watchOS are in a later patch. llvm-svn: 251708
2015-10-31 00:30:36 +08:00
case ObjCRuntime::WatchOS:
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
ObjCRuntime.reset(CreateMacObjCRuntime(*this));
Restructure how the driver communicates information about the target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
2012-06-20 14:18:46 +08:00
return;
}
llvm_unreachable("bad runtime kind");
Created __builtin___NSStringMakeConstantString() builtin, which generates constant Objective-C strings. llvm-svn: 94274
2010-01-23 10:40:42 +08:00
}
OpenCL: introduce support for function scope __local variables llvm-svn: 140068
2011-09-20 05:14:35 +08:00
void CodeGenModule::createOpenCLRuntime() {
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
OpenCLRuntime.reset(new CGOpenCLRuntime(*this));
OpenCL: introduce support for function scope __local variables llvm-svn: 140068
2011-09-20 05:14:35 +08:00
}
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 18:08:46 +08:00
void CodeGenModule::createOpenMPRuntime() {
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
2016-02-08 23:59:20 +08:00
// Select a specialized code generation class based on the target, if any.
// If it does not exist use the default implementation.
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
switch (getTriple().getArch()) {
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
2016-02-08 23:59:20 +08:00
case llvm::Triple::nvptx:
case llvm::Triple::nvptx64:
assert(getLangOpts().OpenMPIsDevice &&
"OpenMP NVPTX is only prepared to deal with device code.");
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
OpenMPRuntime.reset(new CGOpenMPRuntimeNVPTX(*this));
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
2016-02-08 23:59:20 +08:00
break;
default:
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
OpenMPRuntime.reset(new CGOpenMPRuntime(*this));
Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
2016-02-08 23:59:20 +08:00
break;
}
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 18:08:46 +08:00
}
CUDA: IR generation support for kernel call expressions llvm-svn: 141300
2011-10-07 02:29:37 +08:00
void CodeGenModule::createCUDARuntime() {
[CodeGen] Avoid ctor/dtor boilerplate with some C++11 Non-owning pointers that cache LLVM types and constants can use 'nullptr' default member initializers so that we don't need to mention them in the constructor initializer list. Owning pointers should use std::unique_ptr so that we don't need to manually delete them in the destructor. They also don't need to be mentioned in the constructor at that point. NFC llvm-svn: 266263
2016-04-14 07:37:17 +08:00
CUDARuntime.reset(CreateNVCUDARuntime(*this));
CUDA: IR generation support for kernel call expressions llvm-svn: 141300
2011-10-07 02:29:37 +08:00
}
Add support for putting constructors and destructos in explicit comdats. There are situations when clang knows that the C1 and C2 constructors or the D1 and D2 destructors are identical. We already optimize some of these cases, but cannot optimize it when the GlobalValue is weak_odr. The problem with weak_odr is that an old TU seeing the same code will have a C1 and a C2 comdat with the corresponding symbols. We cannot suddenly start putting the C2 symbol in the C1 comdat as we cannot guarantee that the linker will not pick a .o with only C1 in it. The solution implemented by GCC is to expand the ABI to have a comdat whose name uses a C5/D5 suffix and always has both symbols. That is what this patch implements. llvm-svn: 217874
2014-09-16 23:18:21 +08:00
void CodeGenModule::addReplacement(StringRef Name, llvm::Constant *C) {
Replacements[Name] = C;
}
Produce direct calls instead of alias to linkonce_odr functions. This is a small optimization on linux, but should help more on windows where msvc only outputs one destructor if there would be two identical ones. llvm-svn: 194095
2013-11-06 05:37:29 +08:00
void CodeGenModule::applyReplacements() {
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (auto &I : Replacements) {
StringRef MangledName = I.first();
llvm::Constant *Replacement = I.second;
Produce direct calls instead of alias to linkonce_odr functions. This is a small optimization on linux, but should help more on windows where msvc only outputs one destructor if there would be two identical ones. llvm-svn: 194095
2013-11-06 05:37:29 +08:00
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
if (!Entry)
continue;
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *OldF = cast<llvm::Function>(Entry);
auto *NewF = dyn_cast<llvm::Function>(Replacement);
Keep the old function order in CodeGenModule::applyReplacements. The original decls are created when used. The replacements are created at the end of the TU in reverse order. This makes the original order far better for testing. This is particularly important since the replacement logic could be used even when -mconstructor-aliases is not used, but that would make many tests hard to read. This is a fixed version of r194357 which handles replacing a destructor with another which is an alias to a third one. llvm-svn: 194452
2013-11-12 12:53:19 +08:00
if (!NewF) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *Alias = dyn_cast<llvm::GlobalAlias>(Replacement)) {
Use getAliasee instead of getAliasedGlobal. No functionality change. llvm-svn: 209038
2014-05-17 06:20:18 +08:00
NewF = dyn_cast<llvm::Function>(Alias->getAliasee());
[ms-cxxabi] Fix cast when structor replacement is an alias llvm-svn: 200711
2014-02-04 02:54:51 +08:00
} else {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *CE = cast<llvm::ConstantExpr>(Replacement);
[ms-cxxabi] Fix cast when structor replacement is an alias llvm-svn: 200711
2014-02-04 02:54:51 +08:00
assert(CE->getOpcode() == llvm::Instruction::BitCast ||
CE->getOpcode() == llvm::Instruction::GetElementPtr);
NewF = dyn_cast<llvm::Function>(CE->getOperand(0));
}
Keep the old function order in CodeGenModule::applyReplacements. The original decls are created when used. The replacements are created at the end of the TU in reverse order. This makes the original order far better for testing. This is particularly important since the replacement logic could be used even when -mconstructor-aliases is not used, but that would make many tests hard to read. This is a fixed version of r194357 which handles replacing a destructor with another which is an alias to a third one. llvm-svn: 194452
2013-11-12 12:53:19 +08:00
}
// Replace old with new, but keep the old order.
OldF->replaceAllUsesWith(Replacement);
if (NewF) {
NewF->removeFromParent();
CodeGen: Remove implicit ilist iterator conversions, NFC Make ilist iterator conversions explicit in clangCodeGen. Eventually I'll remove them everywhere. llvm-svn: 252358
2015-11-07 07:00:41 +08:00
OldF->getParent()->getFunctionList().insertAfter(OldF->getIterator(),
NewF);
Keep the old function order in CodeGenModule::applyReplacements. The original decls are created when used. The replacements are created at the end of the TU in reverse order. This makes the original order far better for testing. This is particularly important since the replacement logic could be used even when -mconstructor-aliases is not used, but that would make many tests hard to read. This is a fixed version of r194357 which handles replacing a destructor with another which is an alias to a third one. llvm-svn: 194452
2013-11-12 12:53:19 +08:00
}
OldF->eraseFromParent();
Produce direct calls instead of alias to linkonce_odr functions. This is a small optimization on linux, but should help more on windows where msvc only outputs one destructor if there would be two identical ones. llvm-svn: 194095
2013-11-06 05:37:29 +08:00
}
}
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
void CodeGenModule::addGlobalValReplacement(llvm::GlobalValue *GV, llvm::Constant *C) {
GlobalValReplacements.push_back(std::make_pair(GV, C));
}
void CodeGenModule::applyGlobalValReplacements() {
for (auto &I : GlobalValReplacements) {
llvm::GlobalValue *GV = I.first;
llvm::Constant *C = I.second;
GV->replaceAllUsesWith(C);
GV->eraseFromParent();
}
}
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
// This is only used in aliases that we created and we know they have a
// linear structure.
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
static const llvm::GlobalObject *getAliasedGlobal(
const llvm::GlobalIndirectSymbol &GIS) {
llvm::SmallPtrSet<const llvm::GlobalIndirectSymbol*, 4> Visited;
const llvm::Constant *C = &GIS;
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
for (;;) {
This cast is not necessary any more (llvm api change). llvm-svn: 210206
2014-06-05 03:03:20 +08:00
C = C->stripPointerCasts();
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
if (auto *GO = dyn_cast<llvm::GlobalObject>(C))
return GO;
// stripPointerCasts will not walk over weak aliases.
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
auto *GIS2 = dyn_cast<llvm::GlobalIndirectSymbol>(C);
if (!GIS2)
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
return nullptr;
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
if (!Visited.insert(GIS2).second)
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
return nullptr;
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
C = GIS2->getIndirectSymbol();
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
}
}
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
void CodeGenModule::checkAliases() {
Handle and warn on aliases to weak aliases. This produces valid IR now that llvm rejects aliases to weak aliases and warns the user that the resolution is not changed if the weak alias is overridden. llvm-svn: 204935
2014-03-27 23:27:20 +08:00
// Check if the constructed aliases are well formed. It is really unfortunate
// that we have to do this in CodeGen, but we only construct mangled names
// and aliases during codegen.
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
bool Error = false;
Small refactoring, no functionality change. llvm-svn: 207991
2014-05-06 03:33:09 +08:00
DiagnosticsEngine &Diags = getDiags();
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (const GlobalDecl &GD : Aliases) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *D = cast<ValueDecl>(GD.getDecl());
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
SourceLocation Location;
bool IsIFunc = D->hasAttr<IFuncAttr>();
if (const Attr *A = D->getDefiningAttr())
Location = A->getLocation();
else
llvm_unreachable("Not an alias or ifunc?");
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
StringRef MangledName = getMangledName(GD);
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
auto *Alias = cast<llvm::GlobalIndirectSymbol>(Entry);
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
const llvm::GlobalValue *GV = getAliasedGlobal(*Alias);
if (!GV) {
Error = true;
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
Diags.Report(Location, diag::err_cyclic_alias) << IsIFunc;
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
} else if (GV->isDeclaration()) {
Simplify code. No functionality change. llvm-svn: 203804
2014-03-13 23:47:50 +08:00
Error = true;
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
Diags.Report(Location, diag::err_alias_to_undefined)
<< IsIFunc << IsIFunc;
} else if (IsIFunc) {
// Check resolver function type.
llvm::FunctionType *FTy = dyn_cast<llvm::FunctionType>(
GV->getType()->getPointerElementType());
assert(FTy);
if (!FTy->getReturnType()->isPointerTy())
Diags.Report(Location, diag::err_ifunc_resolver_return);
if (FTy->getNumParams())
Diags.Report(Location, diag::err_ifunc_resolver_params);
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
}
Handle and warn on aliases to weak aliases. This produces valid IR now that llvm rejects aliases to weak aliases and warns the user that the resolution is not changed if the weak alias is overridden. llvm-svn: 204935
2014-03-27 23:27:20 +08:00
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
llvm::Constant *Aliasee = Alias->getIndirectSymbol();
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
llvm::GlobalValue *AliaseeGV;
if (auto CE = dyn_cast<llvm::ConstantExpr>(Aliasee))
AliaseeGV = cast<llvm::GlobalValue>(CE->getOperand(0));
else
AliaseeGV = cast<llvm::GlobalValue>(Aliasee);
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
if (const SectionAttr *SA = D->getAttr<SectionAttr>()) {
StringRef AliasSection = SA->getName();
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
if (AliasSection != AliaseeGV->getSection())
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
Diags.Report(SA->getLocation(), diag::warn_alias_with_section)
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
<< AliasSection << IsIFunc << IsIFunc;
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
}
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
// We have to handle alias to weak aliases in here. LLVM itself disallows
// this since the object semantics would not match the IL one. For
// compatibility with gcc we implement it by just pointing the alias
// to its aliasee's aliasee. We also warn, since the user is probably
// expecting the link to be weak.
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
if (auto GA = dyn_cast<llvm::GlobalIndirectSymbol>(AliaseeGV)) {
Adapt to LLVM API change Replace mayBeOverridden with isInterposable llvm-svn: 265767
2016-04-08 09:31:02 +08:00
if (GA->isInterposable()) {
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
Diags.Report(Location, diag::warn_alias_to_weak_alias)
<< GV->getName() << GA->getName() << IsIFunc;
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
Aliasee = llvm::ConstantExpr::getPointerBitCastOrAddrSpaceCast(
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
GA->getIndirectSymbol(), Alias->getType());
Alias->setIndirectSymbol(Aliasee);
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
}
}
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
}
if (!Error)
return;
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (const GlobalDecl &GD : Aliases) {
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
StringRef MangledName = getMangledName(GD);
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
auto *Alias = dyn_cast<llvm::GlobalIndirectSymbol>(Entry);
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
Alias->replaceAllUsesWith(llvm::UndefValue::get(Alias->getType()));
Alias->eraseFromParent();
}
}
When we decide to output a deferred decl, remember the llvm GlobalValue. We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already emitted or not. This fixes a 2010 TODO. llvm-svn: 196785
2013-12-09 22:59:08 +08:00
void CodeGenModule::clear() {
DeferredDeclsToEmit.clear();
[OPENMP] Fix crash on code emitting if errors are found. Codegen for threadprivate variables (and in some other cases) may cause crash of the compiler if some diagnostic is produced later. This happens because some of the autogenerated globals are not removed from InternalVars StringMap when llvm::Module is reset. Differential Revision: http://reviews.llvm.org/D8360 llvm-svn: 232610
2015-03-18 12:13:55 +08:00
if (OpenMPRuntime)
OpenMPRuntime->clear();
When we decide to output a deferred decl, remember the llvm GlobalValue. We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already emitted or not. This fixes a 2010 TODO. llvm-svn: 196785
2013-12-09 22:59:08 +08:00
}
CodeGen: Improve warnings about uninstrumented files when profiling Improve the warning when building with -fprofile-instr-use and a file appears not to have been profiled at all. This keys on whether a function is defined in the main file or not to avoid false negatives when one includes a header with functions that have been profiled. llvm-svn: 211760
2014-06-26 09:45:07 +08:00
void InstrProfStats::reportDiagnostics(DiagnosticsEngine &Diags,
StringRef MainFile) {
if (!hasDiagnostics())
return;
if (VisitedInMainFile > 0 && VisitedInMainFile == MissingInMainFile) {
if (MainFile.empty())
MainFile = "<stdin>";
Diags.Report(diag::warn_profile_data_unprofiled) << MainFile;
[Profile] Add off-by-default -Wprofile-instr-missing warning Clang warns that a profile is out-of-date if it can't find a profile record for any function in a TU. This warning became noisy after llvm started allowing dead-stripping of instrumented functions. To fix this, this patch changes the existing profile out-of-date warning (-Wprofile-instr-out-of-date) so that it only complains about mismatched data. Further, it introduces a new, off-by-default warning about missing function data (-Wprofile-instr-missing). Differential Revision: https://reviews.llvm.org/D28867 llvm-svn: 301570
2017-04-28 01:30:58 +08:00
} else {
if (Mismatched > 0)
Diags.Report(diag::warn_profile_data_out_of_date) << Visited << Mismatched;
if (Missing > 0)
Diags.Report(diag::warn_profile_data_missing) << Visited << Missing;
}
CodeGen: Improve warnings about uninstrumented files when profiling Improve the warning when building with -fprofile-instr-use and a file appears not to have been profiled at all. This keys on whether a function is defined in the main file or not to avoid false negatives when one includes a header with functions that have been profiled. llvm-svn: 211760
2014-06-26 09:45:07 +08:00
}
Refactored driver logic for CodeGen into LLVMCodeGenWriter. This ASTConsumer layers on top of LLVMCodeGen (another existing ASTConsumer) to emit bitcode files to disk. This layering takes this logic out of clang.cpp and puts it directly into the ASTConsumer interface. The benefit is that now --emit-llvm works with both serialized ASTs and regular source files. llvm-svn: 54364
2008-08-06 02:50:11 +08:00
void CodeGenModule::Release() {
fix PR3200 by making alias emission use the new infrastructure. Fold some tests into the alias.c file. llvm-svn: 67479
2009-03-23 05:21:57 +08:00
EmitDeferred();
Emit available_externally vtables opportunistically Summary: We can emit vtable definition having inline function if they are all emitted. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33437 llvm-svn: 304394
2017-06-01 16:04:05 +08:00
EmitVTablesOpportunistically();
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
applyGlobalValReplacements();
Produce direct calls instead of alias to linkonce_odr functions. This is a small optimization on linux, but should help more on windows where msvc only outputs one destructor if there would be two identical ones. llvm-svn: 194095
2013-11-06 05:37:29 +08:00
applyReplacements();
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
checkAliases();
Fix for PR5967: Make const-marking for LLVM globals correct for cases requiring run-time initialization, and emit run-time initializers aggresively to avoid ordering issues with deferred globals. llvm-svn: 92976
2010-01-08 08:50:11 +08:00
EmitCXXGlobalInitFunc();
C++: Add support for -fno-use-cxa-atexit. - So much typing, so little gain... Also, rename the __cxx_global_initialization function just to match llvm-gcc. llvm-svn: 99039
2010-03-20 12:15:41 +08:00
EmitCXXGlobalDtorFunc();
Implement CodeGen for C++11 thread_local, following the Itanium ABI specification as discussed on cxx-abi-dev. llvm-svn: 179858
2013-04-20 00:42:07 +08:00
EmitCXXThreadLocalInitFunc();
CodeGen: rename CodeGenModule::Runtime to ObjCRuntime llvm-svn: 136254
2011-07-28 04:29:46 +08:00
if (ObjCRuntime)
if (llvm::Function *ObjCInitFunction = ObjCRuntime->ModuleInitFunction())
Change CodeGenModule to only create ObjC runtime for ObjC files - Changed CodeGenModule::getObjCRuntime to return reference. - Added CodeGenModule::hasObjCRuntime predicate. llvm-svn: 54645
2008-08-12 02:12:00 +08:00
AddGlobalCtor(ObjCInitFunction);
[cuda] Include GPU binary into host object file and generate init/deinit code. - added -fcuda-include-gpubinary option to incorporate results of device-side compilation into host-side one. - generate code to register GPU binaries and associated kernels with CUDA runtime and clean-up on exit. - added test case for init/deinit code generation. Differential Revision: http://reviews.llvm.org/D9507 llvm-svn: 236765
2015-05-08 03:34:16 +08:00
if (Context.getLangOpts().CUDA && !Context.getLangOpts().CUDAIsDevice &&
CUDARuntime) {
if (llvm::Function *CudaCtorFunction = CUDARuntime->makeModuleCtorFunction())
AddGlobalCtor(CudaCtorFunction);
if (llvm::Function *CudaDtorFunction = CUDARuntime->makeModuleDtorFunction())
AddGlobalDtor(CudaDtorFunction);
}
[OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and device codegen. This patch attempts to fix the regressions identified when the patch was committed initially. Thanks to Michael Liao for identifying the fix in the offloading metadata generation related with side effects in evaluation of function arguments. llvm-svn: 256933
2016-01-06 21:42:12 +08:00
if (OpenMPRuntime)
if (llvm::Function *OpenMPRegistrationFunction =
[OpenMP] Create COMDAT group for OpenMP offload registration code to avoid multiple copies Thanks to Sergey Dmitriev for submitting the patch. Differential Revision: https://reviews.llvm.org/D33509 llvm-svn: 304056
2017-05-27 11:03:13 +08:00
OpenMPRuntime->emitRegistrationFunction()) {
auto ComdatKey = OpenMPRegistrationFunction->hasComdat() ?
OpenMPRegistrationFunction : nullptr;
AddGlobalCtor(OpenMPRegistrationFunction, 0, ComdatKey);
}
Attach maximum function count to Module when using PGO mode. This sets the maximum entry count among all functions in the program to the module using module flags. This allows the optimizer to use this information. Differential Revision: http://reviews.llvm.org/D15163 llvm-svn: 255918
2015-12-18 03:14:27 +08:00
if (PGOReader) {
Attach profile summary information to Module. Differential Revision: http://reviews.llvm.org/D18289 llvm-svn: 264342
2016-03-25 05:32:25 +08:00
getModule().setProfileSummary(PGOReader->getSummary().getMD(VMContext));
Attach maximum function count to Module when using PGO mode. This sets the maximum entry count among all functions in the program to the module using module flags. This allows the optimizer to use this information. Differential Revision: http://reviews.llvm.org/D15163 llvm-svn: 255918
2015-12-18 03:14:27 +08:00
if (PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
}
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
EmitGlobalAnnotations();
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
EmitStaticExternCAliases();
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
EmitDeferredUnusedCoverageMappings();
if (CoverageMapping)
CoverageMapping->emit();
[cfi] Emit __cfi_check stub in the frontend. Previously __cfi_check was created in LTO optimization pipeline, which means LLD has no way of knowing about the existence of this symbol without rescanning the LTO output object. As a result, LLD fails to export __cfi_check, even when given --export-dynamic-symbol flag. llvm-svn: 299806
2017-04-08 07:00:38 +08:00
if (CodeGenOpts.SanitizeCfiCrossDso) {
[cfi] Cross-DSO CFI diagnostic mode (clang part) * Runtime diagnostic data for cfi-icall changed to match the rest of cfi checks * Layout of all CFI diagnostic data changed to put Kind at the beginning. There is no ABI stability promise yet. * Call cfi_slowpath_diag instead of cfi_slowpath when needed. * Emit __cfi_check_fail function, which dispatches a CFI check faliure according to trap/recover settings of the current module. * A tiny driver change to match the way the new handlers are done in compiler-rt. llvm-svn: 258745
2016-01-26 07:34:52 +08:00
CodeGenFunction(*this).EmitCfiCheckFail();
[cfi] Emit __cfi_check stub in the frontend. Previously __cfi_check was created in LTO optimization pipeline, which means LLD has no way of knowing about the existence of this symbol without rescanning the LTO output object. As a result, LLD fails to export __cfi_check, even when given --export-dynamic-symbol flag. llvm-svn: 299806
2017-04-08 07:00:38 +08:00
CodeGenFunction(*this).EmitCfiCheckStub();
}
[CodeGen] Emit a CoreFoundation link guard when @available is used After r297760, __isOSVersionAtLeast in compiler-rt loads the CoreFoundation symbols at runtime. This means that `@available` will always fail when used in a binary without a linked CoreFoundation. This commit forces Clang to emit a reference to a CoreFoundation symbol when `@available` is used to ensure that linking will fail when CoreFoundation isn't linked with the build product. rdar://31039592 Differential Revision: https://reviews.llvm.org/D30977 llvm-svn: 298588
2017-03-23 19:14:27 +08:00
emitAtAvailableLinkGuard();
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
emitLLVMUsed();
Introduce -fsanitize-stats flag. This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
2016-01-16 08:31:22 +08:00
if (SanStats)
SanStats->finish();
Add -fmodules-autolink/-fno-modules-autolink (defaults to on) so that users can explicitly enable/disable modules autolinking. llvm-svn: 172592
2013-01-16 09:23:41 +08:00
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
if (CodeGenOpts.Autolink &&
(Context.getLangOpts().Modules || !LinkerOptionsMetadata.empty())) {
Add -fmodules-autolink/-fno-modules-autolink (defaults to on) so that users can explicitly enable/disable modules autolinking. llvm-svn: 172592
2013-01-16 09:23:41 +08:00
EmitModuleLinkOptions();
}
[X86] Add NumRegisterParameters Module Flag. Reviewers: rnk, mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27051 llvm-svn: 298177
2017-03-18 08:43:39 +08:00
Move NumRegParameters Module Flag. NFCI. llvm-svn: 299079
2017-03-30 21:41:44 +08:00
// Record mregparm value now so it is visible through rest of codegen.
if (Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
getModule().addModuleFlag(llvm::Module::Error, "NumRegisterParameters",
CodeGenOpts.NumRegisterParameters);
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Add -gcodeview and -gdwarf to control which type Clang emits Summary: By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can force emission of one or both by passing -gcodeview and -gdwarf to either driver. Reviewers: dblaikie, hans Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11742 llvm-svn: 244097
2015-08-06 02:51:13 +08:00
if (CodeGenOpts.DwarfVersion) {
Debug Info: support for gdwarf-2 gdwarf-3 gdwarf-4 These options will add a module flag with name "Dwarf Version". The behavior flag is currently set to Warning, so when two values disagree, a warning will be emitted. llvm-svn: 184276
2013-06-19 09:46:49 +08:00
// We actually want the latest version when there are conflicts.
// We can change from Warning to Latest if such mode is supported.
getModule().addModuleFlag(llvm::Module::Warning, "Dwarf Version",
CodeGenOpts.DwarfVersion);
Add -gcodeview and -gdwarf to control which type Clang emits Summary: By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can force emission of one or both by passing -gcodeview and -gdwarf to either driver. Reviewers: dblaikie, hans Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11742 llvm-svn: 244097
2015-08-06 02:51:13 +08:00
}
if (CodeGenOpts.EmitCodeView) {
// Indicate that we want CodeView in the metadata.
getModule().addModuleFlag(llvm::Module::Warning, "CodeView", 1);
}
Added llvm.module flag for strict vtable pointers It is dangerous to do LTO on code with strict-vtable-pointers, because one module has invariant.group.barriers, and the other one not. In the future I want to just strip all invariant.group metadata from vptrs loads/stores and get rid of invariant.group.barrier calls. http://reviews.llvm.org/D12580 llvm-svn: 247724
2015-09-16 05:46:50 +08:00
if (CodeGenOpts.OptimizationLevel > 0 && CodeGenOpts.StrictVTablePointers) {
// We don't support LTO with 2 with different StrictVTablePointers
// FIXME: we could support it by stripping all the information introduced
// by StrictVTablePointers.
getModule().addModuleFlag(llvm::Module::Error, "StrictVTablePointers",1);
llvm::Metadata *Ops[2] = {
llvm::MDString::get(VMContext, "StrictVTablePointers"),
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
llvm::Type::getInt32Ty(VMContext), 1))};
getModule().addModuleFlag(llvm::Module::Require,
"StrictVTablePointersRequirement",
llvm::MDNode::get(VMContext, Ops));
}
Debug Info: add a "Debug Info Version" module flag to output the current debug info version number. Will error out when modules have different version numbers. llvm-svn: 195495
2013-11-23 03:42:45 +08:00
if (DebugInfo)
Demote the "Debug Info Version" module flag to llvm::Module::Warning behavior on mismatch. The AutoUpgrader will drop incompatible debug info any way and also emit a warning diagnostic for it. rdar://problem/16926122 llvm-svn: 209182
2014-05-20 07:40:06 +08:00
// We support a single version in the linked module. The LLVM
// parser will drop debug info with a different version number
// (and warn about it, too).
getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
Debug Info: Move the constant for Debug Info Version from Dwarf.h to Metadata.h. Suggested by Eric. Paired commit with r196144. llvm-svn: 196145
2013-12-03 04:10:37 +08:00
llvm::DEBUG_METADATA_VERSION);
Switch autolinking metadata format over to actual linker options, e.g., !0 = metadata !{metadata !"-lautolink"} !1 = metadata !{metadata !"-framework", metadata !"autolink_framework"} referenced from llvm.module.linkoptions, e.g., !llvm.module.linkoptions = !{!0, !1, !2, !3} This conceptually moves the logic for figuring out the syntax the linker will accept from LLVM into Clang. Moreover, it makes it easier to support MSVC's #pragma comment(linker, "some option") in the future, should anyone care to do so. llvm-svn: 172441
2013-01-15 02:28:43 +08:00
Add module flags metadata to record the settings for enum and wchar width Add module flags metadata to record the settings for enum and wchar width, to allow correct ARM build attribute generation llvm-svn: 211354
2014-06-20 20:43:07 +08:00
// We need to record the widths of enums and wchar_t, so that we can generate
CodeGenModule: Always output wchar_size, check LLVM assumptions. Re-commit r303463 now that LLVM is fixed and adjust some lit tests. llvm::TargetLibraryInfo needs to know the size of wchar_t to work on functions like `wcslen`. This patch changes clang to always emit the wchar_size module flag (it would only do so for ARM previously). This also adds an `assert()` to ensure the LLVM defaults based on the target triple are in sync with clang. Differential Revision: https://reviews.llvm.org/D32982 llvm-svn: 303478
2017-05-20 09:29:55 +08:00
// the correct build attributes in the ARM backend. wchar_size is also used by
// TargetLibraryInfo.
CodeGenModule: Adapt to LLVM TargetLibraryInfo changes Adapt to LLVM TargetLibraryInfo changes in r314185. See also https://reviews.llvm.org/D38106 and https://reviews.llvm.org/D37891 llvm-svn: 314187
2017-09-26 10:37:23 +08:00
uint64_t WCharWidth =
Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
CodeGenModule: Always output wchar_size, check LLVM assumptions. Re-commit r303463 now that LLVM is fixed and adjust some lit tests. llvm::TargetLibraryInfo needs to know the size of wchar_t to work on functions like `wcslen`. This patch changes clang to always emit the wchar_size module flag (it would only do so for ARM previously). This also adds an `assert()` to ensure the LLVM defaults based on the target triple are in sync with clang. Differential Revision: https://reviews.llvm.org/D32982 llvm-svn: 303478
2017-05-20 09:29:55 +08:00
getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
CodeGen: Remove a stray tab character (NFC) llvm-svn: 211528
2014-06-24 04:03:28 +08:00
llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();
Add module flags metadata to record the settings for enum and wchar width Add module flags metadata to record the settings for enum and wchar width, to allow correct ARM build attribute generation llvm-svn: 211354
2014-06-20 20:43:07 +08:00
if ( Arch == llvm::Triple::arm
|| Arch == llvm::Triple::armeb
|| Arch == llvm::Triple::thumb
|| Arch == llvm::Triple::thumbeb) {
// The minimum width of an enum in bytes
uint64_t EnumWidth = Context.getLangOpts().ShortEnums ? 1 : 4;
getModule().addModuleFlag(llvm::Module::Error, "min_enum_size", EnumWidth);
}
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
if (CodeGenOpts.SanitizeCfiCrossDso) {
// Indicate that we want cross-DSO control flow integrity checks.
getModule().addModuleFlag(llvm::Module::Override, "Cross-DSO CFI", 1);
}
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
if (LangOpts.CUDAIsDevice && getTriple().isNVPTX()) {
[CUDA] Add -fcuda-flush-denormals-to-zero. Summary: Setting this flag causes all functions are annotated with the "nvvm-f32ftz" = "true" attribute. In addition, we annotate the module with "nvvm-reflect-ftz" set to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set. This is read by the NVVMReflect pass. Reviewers: tra, rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18671 llvm-svn: 265435
2016-04-06 02:26:20 +08:00
// Indicate whether __nvvm_reflect should be configured to flush denormal
// floating point values to 0. (This corresponds to its "__CUDA_FTZ"
// property.)
getModule().addModuleFlag(llvm::Module::Override, "nvvm-reflect-ftz",
LangOpts.CUDADeviceFlushDenormalsToZero ? 1 : 0);
}
[OpenCL] Fix OpenCL and SPIR version metadata generation. Summary: OpenCL and SPIR version metadata must be generated once per module instead of once per mangled global value. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: ahatanak, cfe-commits Differential Revision: https://reviews.llvm.org/D34235 llvm-svn: 305796
2017-06-20 22:30:18 +08:00
// Emit OpenCL specific module metadata: OpenCL/SPIR version.
if (LangOpts.OpenCL) {
EmitOpenCLMetadata();
// Emit SPIR version.
if (getTriple().getArch() == llvm::Triple::spir ||
getTriple().getArch() == llvm::Triple::spir64) {
// SPIR v2.0 s2.12 - The SPIR version used by the module is stored in the
// opencl.spir.version named metadata.
llvm::Metadata *SPIRVerElts[] = {
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
Int32Ty, LangOpts.OpenCLVersion / 100)),
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
Int32Ty, (LangOpts.OpenCLVersion / 100 > 1) ? 0 : 2))};
llvm::NamedMDNode *SPIRVerMD =
TheModule.getOrInsertNamedMetadata("opencl.spir.version");
llvm::LLVMContext &Ctx = TheModule.getContext();
SPIRVerMD->addOperand(llvm::MDNode::get(Ctx, SPIRVerElts));
}
}
Add PIC-level support to Clang. Summary: This distinguishes between -fpic and -fPIC now, with the additions in LLVM for PIC level support. Test Plan: No regressions Reviewers: echristo, rafael Reviewed By: rafael Subscribers: rnk, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5400 llvm-svn: 222227
2014-11-18 14:17:20 +08:00
if (uint32_t PLevel = Context.getLangOpts().PICLevel) {
Differential Revision: http://reviews.llvm.org/D19687 Set module flag PIELevel. Simplify code that sets PICLevel flag. llvm-svn: 267948
2016-04-29 06:34:00 +08:00
assert(PLevel < 3 && "Invalid PIC Level");
getModule().setPICLevel(static_cast<llvm::PICLevel::Level>(PLevel));
Restructure the propagation of -fPIC/-fPIE. The PIC and PIE levels are not independent. In fact, if PIE is defined it is always the same as PIC. This is clear in the driver where ParsePICArgs returns a PIC level and a IsPIE boolean. Unfortunately that is currently lost and we pass two redundant levels down the pipeline. This patch keeps a bool and a PIC level all the way down to codegen. llvm-svn: 273566
2016-06-23 23:07:32 +08:00
if (Context.getLangOpts().PIE)
getModule().setPIELevel(static_cast<llvm::PIELevel::Level>(PLevel));
Add PIC-level support to Clang. Summary: This distinguishes between -fpic and -fPIC now, with the additions in LLVM for PIC level support. Test Plan: No regressions Reviewers: echristo, rafael Reviewed By: rafael Subscribers: rnk, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5400 llvm-svn: 222227
2014-11-18 14:17:20 +08:00
}
Opportunistically use the C++ personality function in ObjC++ translation units that don't catch ObjC types. rdar://problem/8434851 llvm-svn: 114070
2010-09-16 14:16:50 +08:00
SimplifyPersonality();
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
if (getCodeGenOpts().EmitDeclMetadata)
EmitDeclMetadata();
Record where the GCOV data files should be placed. llvm-svn: 130866
2011-05-05 04:46:58 +08:00
if (getCodeGenOpts().EmitGcovArcs || getCodeGenOpts().EmitGcovNotes)
Preserve the full name of the file, so that '-c -o foo.pic.o' produces foo.pic.gcno instead of foo.gcno. llvm-svn: 130899
2011-05-05 08:08:20 +08:00
EmitCoverageFile();
Finalize debug info after all deferred globals are emitted. llvm-svn: 137750
2011-08-17 04:58:22 +08:00
if (DebugInfo)
DebugInfo->finalize();
Emit a .ident saying that clang produced this file. Patch by Katya Romanova. llvm-svn: 192832
2013-10-17 03:28:50 +08:00
EmitVersionIdentMetadata();
Move the calling of emitTargetMD() later. Summary: Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz: extern char a[]; char f(){ return a[5];} char a[10]; Change MangledDeclNames to use a MapVector rather than a DenseMap so that the Metadata is output in order of original declaration, so to make deterministic and improve human readablity. Differential Revision: http://reviews.llvm.org/D4176 llvm-svn: 212263
2014-07-03 17:30:33 +08:00
EmitTargetMetadata();
Add simple interface for protecting runtime functions from name collisions. - Provide CodeGenModule::CreateRuntimeFunction which guarantees that the function it creates will have the provided name in the final module. This allows the runtime to have its functions protected from declarations of the same name in the source code. - One could argue that this is a reason to abuse the llvm::Module namespace for dealing with function redeclarations. However, that approach seems conceptually flawed to me. This one also happens to be somewhat more efficient. No functionality change. llvm-svn: 56899
2008-10-01 08:49:24 +08:00
}
[OpenCL] Fix OpenCL and SPIR version metadata generation. Summary: OpenCL and SPIR version metadata must be generated once per module instead of once per mangled global value. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: ahatanak, cfe-commits Differential Revision: https://reviews.llvm.org/D34235 llvm-svn: 305796
2017-06-20 22:30:18 +08:00
void CodeGenModule::EmitOpenCLMetadata() {
// SPIR v2.0 s2.13 - The OpenCL version used by the module is stored in the
// opencl.ocl.version named metadata node.
llvm::Metadata *OCLVerElts[] = {
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
Int32Ty, LangOpts.OpenCLVersion / 100)),
llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
Int32Ty, (LangOpts.OpenCLVersion % 100) / 10))};
llvm::NamedMDNode *OCLVerMD =
TheModule.getOrInsertNamedMetadata("opencl.ocl.version");
llvm::LLVMContext &Ctx = TheModule.getContext();
OCLVerMD->addOperand(llvm::MDNode::get(Ctx, OCLVerElts));
}
Update type cache when a type is completed. Radar 9168773 llvm-svn: 128150
2011-03-24 00:29:39 +08:00
void CodeGenModule::UpdateCompletedType(const TagDecl *TD) {
// Make sure that this type is translated.
Types.UpdateCompletedType(TD);
}
[MS ABI] Allow a member pointers' converted type to change Member pointers in the MS ABI are tricky for a variety of reasons. The size of a member pointer is indeterminate until the program reaches a point where the representation is required to be known. However, *pointers* to member pointers may exist without knowing the pointee type's representation. In these cases, we synthesize an opaque LLVM type for the pointee type. However, we can be in a situation where the underlying member pointer's representation became known mid-way through the program. To account for this, we attempted to manicure CodeGen's type-cache so that we can replace the opaque member pointer type with the real deal while leaving the pointer types unperturbed. This, unfortunately, is a problematic approach to take as we will violate CodeGen's invariants. These violations are mostly harmless but let's do the right thing instead: invalidate the type-cache if a member pointer's LLVM representation changes. This fixes PR26313. llvm-svn: 258839
2016-01-27 03:30:26 +08:00
void CodeGenModule::RefreshTypeCacheForClass(const CXXRecordDecl *RD) {
// Make sure that this type is translated.
Types.RefreshTypeCacheForClass(RD);
}
[CodeGen] Do not refer to complete TBAA info where we actually deal with 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
2017-10-02 17:54:47 +08:00
llvm::MDNode *CodeGenModule::getTBAATypeInfo(QualType QTy) {
Experimental TBAA support. This enables metadata generation by default, however the TBAA pass in the optimizer is still disabled for now. llvm-svn: 116536
2010-10-15 07:06:10 +08:00
if (!TBAA)
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
[CodeGen] Do not refer to complete TBAA info where we actually deal with 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
2017-10-02 17:54:47 +08:00
return TBAA->getTypeInfo(QTy);
Experimental TBAA support. This enables metadata generation by default, however the TBAA pass in the optimizer is still disabled for now. llvm-svn: 116536
2010-10-15 07:06:10 +08:00
}
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
TBAAAccessInfo CodeGenModule::getTBAAAccessInfo(QualType AccessType) {
[CodeGen] Collect information about sizes of accesses and access types for TBAA The information about access and type sizes is necessary for producing TBAA metadata in the new size-aware format. With this patch, D39955 and D39956 in place we should be able to change CodeGenTBAA::createScalarTypeNode() and CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new format under the -new-struct-path-tbaa command-line option. For now, this new information remains unused. Differential Revision: https://reviews.llvm.org/D40176 llvm-svn: 319012
2017-11-27 17:39:29 +08:00
// Pointee values may have incomplete types, but they shall never be
// dereferenced.
if (AccessType->isIncompleteType())
return TBAAAccessInfo::getIncompleteInfo();
uint64_t Size = Context.getTypeSizeInChars(AccessType).getQuantity();
return TBAAAccessInfo(getTBAATypeInfo(AccessType), Size);
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
}
[CodeGen] Collect information about sizes of accesses and access types for TBAA The information about access and type sizes is necessary for producing TBAA metadata in the new size-aware format. With this patch, D39955 and D39956 in place we should be able to change CodeGenTBAA::createScalarTypeNode() and CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new format under the -new-struct-path-tbaa command-line option. For now, this new information remains unused. Differential Revision: https://reviews.llvm.org/D40176 llvm-svn: 319012
2017-11-27 17:39:29 +08:00
TBAAAccessInfo
CodeGenModule::getTBAAVTablePtrAccessInfo(llvm::Type *VTablePtrType) {
add tbaa metadata to vtable pointer loads/stores llvm-svn: 153447
2012-03-27 01:03:51 +08:00
if (!TBAA)
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
return TBAAAccessInfo();
[CodeGen] Collect information about sizes of accesses and access types for TBAA The information about access and type sizes is necessary for producing TBAA metadata in the new size-aware format. With this patch, D39955 and D39956 in place we should be able to change CodeGenTBAA::createScalarTypeNode() and CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new format under the -new-struct-path-tbaa command-line option. For now, this new information remains unused. Differential Revision: https://reviews.llvm.org/D40176 llvm-svn: 319012
2017-11-27 17:39:29 +08:00
return TBAA->getVTablePtrAccessInfo(VTablePtrType);
add tbaa metadata to vtable pointer loads/stores llvm-svn: 153447
2012-03-27 01:03:51 +08:00
}
Add basic support for adding !tbaa.struct metadata on llvm.memcpy calls for struct assignment. llvm-svn: 164853
2012-09-29 05:58:29 +08:00
llvm::MDNode *CodeGenModule::getTBAAStructInfo(QualType QTy) {
if (!TBAA)
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
Add basic support for adding !tbaa.struct metadata on llvm.memcpy calls for struct assignment. llvm-svn: 164853
2012-09-29 05:58:29 +08:00
return TBAA->getTBAAStructInfo(QTy);
}
Refine generation of TBAA information in clang 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
2017-10-06 16:17:48 +08:00
llvm::MDNode *CodeGenModule::getTBAABaseTypeInfo(QualType QTy) {
if (!TBAA)
return nullptr;
return TBAA->getBaseTypeInfo(QTy);
}
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
llvm::MDNode *CodeGenModule::getTBAAAccessTagInfo(TBAAAccessInfo Info) {
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
if (!TBAA)
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
return TBAA->getAccessTagInfo(Info);
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
}
[CodeGen] Propagate may-alias'ness of lvalues with TBAA info 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
2017-10-31 19:05:34 +08:00
TBAAAccessInfo CodeGenModule::mergeTBAAInfoForCast(TBAAAccessInfo SourceInfo,
TBAAAccessInfo TargetInfo) {
[CodeGen] Have a special function to get TBAA info for may-alias accesses This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38408 llvm-svn: 314660
2017-10-02 19:10:04 +08:00
if (!TBAA)
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
return TBAAAccessInfo();
[CodeGen] Propagate may-alias'ness of lvalues with TBAA info 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
2017-10-31 19:05:34 +08:00
return TBAA->mergeTBAAInfoForCast(SourceInfo, TargetInfo);
[CodeGen] Have a special function to get TBAA info for may-alias accesses This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38408 llvm-svn: 314660
2017-10-02 19:10:04 +08:00
}
[CodeGen] Propagate may-alias'ness of lvalues with TBAA info 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
2017-10-31 19:05:34 +08:00
TBAAAccessInfo
CodeGenModule::mergeTBAAInfoForConditionalOperator(TBAAAccessInfo InfoA,
TBAAAccessInfo InfoB) {
[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
2017-10-17 17:12:13 +08:00
if (!TBAA)
return TBAAAccessInfo();
[CodeGen] Propagate may-alias'ness of lvalues with TBAA info 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
2017-10-31 19:05:34 +08:00
return TBAA->mergeTBAAInfoForConditionalOperator(InfoA, InfoB);
[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
2017-10-17 17:12:13 +08:00
}
Decorating vptr load & stores with !invariant.group Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12026 llvm-svn: 247725
2015-09-16 05:46:55 +08:00
void CodeGenModule::DecorateInstructionWithTBAA(llvm::Instruction *Inst,
[CodeGen] Unify generation of scalar and struct-path TBAA tags 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: 314979
2017-10-05 19:08:17 +08:00
TBAAAccessInfo TBAAInfo) {
if (llvm::MDNode *Tag = getTBAAAccessTagInfo(TBAAInfo))
Inst->setMetadata(llvm::LLVMContext::MD_tbaa, Tag);
Experimental TBAA support. This enables metadata generation by default, however the TBAA pass in the optimizer is still disabled for now. llvm-svn: 116536
2010-10-15 07:06:10 +08:00
}
Decorating vptr load & stores with !invariant.group Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12026 llvm-svn: 247725
2015-09-16 05:46:55 +08:00
void CodeGenModule::DecorateInstructionWithInvariantGroup(
llvm::Instruction *I, const CXXRecordDecl *RD) {
[Devirtualization] Emit invariant.group loads with empty group md Summary: As discussed here http://lists.llvm.org/pipermail/llvm-dev/2017-January/109332.html having different groups doesn't solve the problem entirly. Reviewers: rjmccall, rsmith Subscribers: amharc, cfe-commits Differential Revision: https://reviews.llvm.org/D32110 llvm-svn: 301178
2017-04-24 20:58:43 +08:00
I->setMetadata(llvm::LLVMContext::MD_invariant_group,
llvm::MDNode::get(getLLVMContext(), {}));
Decorating vptr load & stores with !invariant.group Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12026 llvm-svn: 247725
2015-09-16 05:46:55 +08:00
}
Enforce safe usage of DiagnosticsEngine::getCustomDiagID() Replace the last incorrect uses and templatize the function to require a compile-time constant string preventing further misuse. The diagnostic formatter expects well-formed input and has undefined behaviour with arbitrary input or crafted user strings in source files. Accepting user input would also have caused unbounded generation of new diagnostic IDs which can be problematic in long-running sessions or language bindings. This completes the work to fix several incorrect callers that passed user input or raw messages to the diagnostics engine where a constant format string was expected. llvm-svn: 200132
2014-01-26 14:17:37 +08:00
void CodeGenModule::Error(SourceLocation loc, StringRef message) {
unsigned diagID = getDiags().getCustomDiagID(DiagnosticsEngine::Error, "%0");
getDiags().Report(Context.getFullLoc(loc), diagID) << message;
The Darwin kernel does not provide useful guard variable support. Issue this as an IR-gen error; it's not really worthwhile doing this "right", i.e. in Sema, because IR gen knows a lot of tricks beyond what the constant evaluator knows. llvm-svn: 127854
2011-03-18 10:56:14 +08:00
}
Change WarnUnsupported to ErrorUnsupported (in name and in practice). - We are beyond the point where this shows up often and when it does generating miscompiled files is bad. llvm-svn: 54836
2008-08-16 08:56:44 +08:00
/// ErrorUnsupported - Print out an error that codegen doesn't support the
warn about unhandled initializers instead of crashing on them. llvm-svn: 44510
2007-12-02 15:19:18 +08:00
/// specified stmt yet.
PR16933: Don't try to codegen things after we've seen errors. Refactor the underlying code a bit to remove unnecessary calls to "hasErrorOccurred" & make them consistently at all the entry points to the IRGen ASTConsumer. llvm-svn: 188707
2013-08-20 05:02:26 +08:00
void CodeGenModule::ErrorUnsupported(const Stmt *S, const char *Type) {
Rename Diagnostic to DiagnosticsEngine as per issue 5397 llvm-svn: 140478
2011-09-26 07:23:43 +08:00
unsigned DiagID = getDiags().getCustomDiagID(DiagnosticsEngine::Error,
Use 'compile' instead of 'codegen' when reporting error to user. llvm-svn: 63952
2009-02-07 03:18:03 +08:00
"cannot compile this %0 yet");
warn about unhandled initializers instead of crashing on them. llvm-svn: 44510
2007-12-02 15:19:18 +08:00
std::string Msg = Type;
This reworks some of the Diagnostic interfaces a bit to change how diagnostics are formed. In particular, a diagnostic with all its strings and ranges is now packaged up and sent to DiagnosticClients as a DiagnosticInfo instead of as a ton of random stuff. This has the benefit of simplifying the interface, making it more extensible, and allowing us to do more checking for things like access past the end of the various arrays passed in. In addition to introducing DiagnosticInfo, this also substantially changes how Diagnostic::Report works. Instead of being passed in all of the info required to issue a diagnostic, Report now takes only the required info (a location and ID) and returns a fresh DiagnosticInfo *by value*. The caller is then free to stuff strings and ranges into the DiagnosticInfo with the << operator. When the dtor runs on the DiagnosticInfo object (which should happen at the end of the statement), the diagnostic is actually emitted with all of the accumulated information. This is a somewhat tricky dance, but it means that the accumulated DiagnosticInfo is allowed to keep pointers to other expression temporaries without those pointers getting invalidated. This is just the minimal change to get this stuff working, but this will allow us to eliminate the zillions of variant "Diag" methods scattered throughout (e.g.) sema. For example, instead of calling: Diag(BuiltinLoc, diag::err_overload_no_match, typeNames, SourceRange(BuiltinLoc, RParenLoc)); We will soon be able to just do: Diag(BuiltinLoc, diag::err_overload_no_match) << typeNames << SourceRange(BuiltinLoc, RParenLoc)); This scales better to support arbitrary types being passed in (not just strings) in a type-safe way. Go operator overloading?! llvm-svn: 59502
2008-11-18 15:04:44 +08:00
getDiags().Report(Context.getFullLoc(S->getLocStart()), DiagID)
<< Msg << S->getSourceRange();
warn about unhandled initializers instead of crashing on them. llvm-svn: 44510
2007-12-02 15:19:18 +08:00
}
implement codegen for functions whose function body type don't match their prototype. llvm-svn: 44506
2007-12-02 14:27:33 +08:00
Change WarnUnsupported to ErrorUnsupported (in name and in practice). - We are beyond the point where this shows up often and when it does generating miscompiled files is bad. llvm-svn: 54836
2008-08-16 08:56:44 +08:00
/// ErrorUnsupported - Print out an error that codegen doesn't support the
Add first pieces of support for parsing and representing extern "C" in C++ mode. Patch by Mike Stump! llvm-svn: 45904
2008-01-12 15:05:38 +08:00
/// specified decl yet.
PR16933: Don't try to codegen things after we've seen errors. Refactor the underlying code a bit to remove unnecessary calls to "hasErrorOccurred" & make them consistently at all the entry points to the IRGen ASTConsumer. llvm-svn: 188707
2013-08-20 05:02:26 +08:00
void CodeGenModule::ErrorUnsupported(const Decl *D, const char *Type) {
Rename Diagnostic to DiagnosticsEngine as per issue 5397 llvm-svn: 140478
2011-09-26 07:23:43 +08:00
unsigned DiagID = getDiags().getCustomDiagID(DiagnosticsEngine::Error,
Use 'compile' instead of 'codegen' when reporting error to user. llvm-svn: 63952
2009-02-07 03:18:03 +08:00
"cannot compile this %0 yet");
Add first pieces of support for parsing and representing extern "C" in C++ mode. Patch by Mike Stump! llvm-svn: 45904
2008-01-12 15:05:38 +08:00
std::string Msg = Type;
This reworks some of the Diagnostic interfaces a bit to change how diagnostics are formed. In particular, a diagnostic with all its strings and ranges is now packaged up and sent to DiagnosticClients as a DiagnosticInfo instead of as a ton of random stuff. This has the benefit of simplifying the interface, making it more extensible, and allowing us to do more checking for things like access past the end of the various arrays passed in. In addition to introducing DiagnosticInfo, this also substantially changes how Diagnostic::Report works. Instead of being passed in all of the info required to issue a diagnostic, Report now takes only the required info (a location and ID) and returns a fresh DiagnosticInfo *by value*. The caller is then free to stuff strings and ranges into the DiagnosticInfo with the << operator. When the dtor runs on the DiagnosticInfo object (which should happen at the end of the statement), the diagnostic is actually emitted with all of the accumulated information. This is a somewhat tricky dance, but it means that the accumulated DiagnosticInfo is allowed to keep pointers to other expression temporaries without those pointers getting invalidated. This is just the minimal change to get this stuff working, but this will allow us to eliminate the zillions of variant "Diag" methods scattered throughout (e.g.) sema. For example, instead of calling: Diag(BuiltinLoc, diag::err_overload_no_match, typeNames, SourceRange(BuiltinLoc, RParenLoc)); We will soon be able to just do: Diag(BuiltinLoc, diag::err_overload_no_match) << typeNames << SourceRange(BuiltinLoc, RParenLoc)); This scales better to support arbitrary types being passed in (not just strings) in a type-safe way. Go operator overloading?! llvm-svn: 59502
2008-11-18 15:04:44 +08:00
getDiags().Report(Context.getFullLoc(D->getLocation()), DiagID) << Msg;
Add first pieces of support for parsing and representing extern "C" in C++ mode. Patch by Mike Stump! llvm-svn: 45904
2008-01-12 15:05:38 +08:00
}
Change the IR-generation of VLAs so that we capture bounds, not sizes; so that we use well-typed allocas; and so that we properly recurse through the full set of variably-modified types. llvm-svn: 133827
2011-06-25 05:55:10 +08:00
llvm::ConstantInt *CodeGenModule::getSize(CharUnits size) {
return llvm::ConstantInt::get(SizeTy, size.getQuantity());
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
void CodeGenModule::setGlobalVisibility(llvm::GlobalValue *GV,
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
const NamedDecl *D,
ForDefinition_t IsForDefinition) const {
Clean up handling of visibility. llvm-svn: 69027
2009-04-14 14:00:08 +08:00
// Internal definitions always have default visibility.
do not set visibility on "private" or "available externally" linkage objects. llvm-svn: 69025
2009-04-14 13:27:13 +08:00
if (GV->hasLocalLinkage()) {
Internal variables could mistakenly have "hidden" visibility when their emission was deferred. - <rdar://problem/6775234> variables with internal linkage should not be exposed with -fvisibility=hidden. llvm-svn: 68818
2009-04-11 04:26:50 +08:00
GV->setVisibility(llvm::GlobalValue::DefaultVisibility);
Various fixes to symbols used for Obj-C x86_64 metadata. - Changed method names to match gcc (categories names still aren't mangled in). - Expose correct name for class and metadata symbols (although -fvisibility=hidden isn't yet correct). - Remove several things from llvm.used that didn't need to be there (I suspect this can still be trimmed). - Don't use asm-prefix extension for _objc_empty_{cache,vtable} (not needed). - Hide EH type class info with -fvisibility=hidden - Change setGlobal[Option]Visibility to not change the visibility of functions with internal linkage. llvm-svn: 68510
2009-04-07 13:48:37 +08:00
return;
Internal variables could mistakenly have "hidden" visibility when their emission was deferred. - <rdar://problem/6775234> variables with internal linkage should not be exposed with -fvisibility=hidden. llvm-svn: 68818
2009-04-11 04:26:50 +08:00
}
Various fixes to symbols used for Obj-C x86_64 metadata. - Changed method names to match gcc (categories names still aren't mangled in). - Expose correct name for class and metadata symbols (although -fvisibility=hidden isn't yet correct). - Remove several things from llvm.used that didn't need to be there (I suspect this can still be trimmed). - Don't use asm-prefix extension for _objc_empty_{cache,vtable} (not needed). - Hide EH type class info with -fvisibility=hidden - Change setGlobal[Option]Visibility to not change the visibility of functions with internal linkage. llvm-svn: 68510
2009-04-07 13:48:37 +08:00
Better solution: calculate the visibility of functions and variables independently of whether they're definitions, then teach IR generation to ignore non-explicit visibility when emitting declarations. Use this to make sure that RTTI, vtables, and VTTs get the right visibility. More of rdar://problem/8613093 llvm-svn: 117781
2010-10-30 19:50:40 +08:00
// Set visibility for definitions.
Move LinkageInfo out of NamedDecl so that it can be used in Type.h. Everything that cares about visibility also cares about linkage, so I just moved it to Visibility.h instead of creating a new .h. llvm-svn: 176155
2013-02-27 10:15:29 +08:00
LinkageInfo LV = D->getLinkageAndVisibility();
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
if (LV.isVisibilityExplicit() ||
(IsForDefinition && !GV->hasAvailableExternallyLinkage()))
Rename methods to comply with the LLVM Coding Standards. llvm-svn: 176159
2013-02-27 10:56:45 +08:00
GV->setVisibility(GetLLVMVisibility(LV.getVisibility()));
Implement -fvisibility. llvm-svn: 68369
2009-04-03 11:28:57 +08:00
}
Add -ftls-model command-line flag. This allows for setting the default TLS model. (PR9788) llvm-svn: 159336
2012-06-28 16:01:44 +08:00
static llvm::GlobalVariable::ThreadLocalMode GetLLVMTLSModel(StringRef S) {
return llvm::StringSwitch<llvm::GlobalVariable::ThreadLocalMode>(S)
.Case("global-dynamic", llvm::GlobalVariable::GeneralDynamicTLSModel)
.Case("local-dynamic", llvm::GlobalVariable::LocalDynamicTLSModel)
.Case("initial-exec", llvm::GlobalVariable::InitialExecTLSModel)
.Case("local-exec", llvm::GlobalVariable::LocalExecTLSModel);
}
static llvm::GlobalVariable::ThreadLocalMode GetLLVMTLSModel(
CodeGenOptions::TLSModel M) {
switch (M) {
case CodeGenOptions::GeneralDynamicTLSModel:
return llvm::GlobalVariable::GeneralDynamicTLSModel;
case CodeGenOptions::LocalDynamicTLSModel:
return llvm::GlobalVariable::LocalDynamicTLSModel;
case CodeGenOptions::InitialExecTLSModel:
return llvm::GlobalVariable::InitialExecTLSModel;
case CodeGenOptions::LocalExecTLSModel:
return llvm::GlobalVariable::LocalExecTLSModel;
}
llvm_unreachable("Invalid TLS model!");
}
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
void CodeGenModule::setTLSMode(llvm::GlobalValue *GV, const VarDecl &D) const {
Annotate flavor of TLS variable (statically or dynamically initialized) onto the AST. llvm-svn: 179447
2013-04-13 10:43:54 +08:00
assert(D.getTLSKind() && "setting TLS mode on non-TLS var!");
Add -ftls-model command-line flag. This allows for setting the default TLS model. (PR9788) llvm-svn: 159336
2012-06-28 16:01:44 +08:00
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
llvm::GlobalValue::ThreadLocalMode TLM;
Switch CodeGenOptions over to a .def file, like we do with LangOptions. llvm-svn: 166497
2012-10-24 04:05:01 +08:00
TLM = GetLLVMTLSModel(CodeGenOpts.getDefaultTLSModel());
Add -ftls-model command-line flag. This allows for setting the default TLS model. (PR9788) llvm-svn: 159336
2012-06-28 16:01:44 +08:00
// Override the TLS model if it is explicitly specified.
Switched code from using hasAttr followed by getAttr to simply call getAttr directly and check the resulting value. No functional changes intended. llvm-svn: 197652
2013-12-19 11:09:10 +08:00
if (const TLSModelAttr *Attr = D.getAttr<TLSModelAttr>()) {
Add -ftls-model command-line flag. This allows for setting the default TLS model. (PR9788) llvm-svn: 159336
2012-06-28 16:01:44 +08:00
TLM = GetLLVMTLSModel(Attr->getModel());
}
GV->setThreadLocalMode(TLM);
}
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef CodeGenModule::getMangledName(GlobalDecl GD) {
[MS ABI] Complete and base constructor GlobalDecls must have the same name Clang got itself into the situation where we mangled the same constructor twice with two different constructor types. After one of the constructors were utilized, the tag used for one of the types changed from class to struct because a class template became complete. This resulted in one of the constructor types varying from the other constructor. Instead, force "base" constructor types to "complete" if the ABI doesn't have constructor variants. This will ensure that GlobalDecls for both variants will get the same mangled name. This fixes PR26029. llvm-svn: 257205
2016-01-09 04:48:26 +08:00
GlobalDecl CanonicalGD = GD.getCanonicalDecl();
// Some ABIs don't have constructor variants. Make sure that base and
// complete constructors get mangled the same.
if (const auto *CD = dyn_cast<CXXConstructorDecl>(CanonicalGD.getDecl())) {
if (!getTarget().getCXXABI().hasConstructorVariants()) {
CXXCtorType OrigCtorType = GD.getCtorType();
assert(OrigCtorType == Ctor_Base || OrigCtorType == Ctor_Complete);
if (OrigCtorType == Ctor_Base)
CanonicalGD = GlobalDecl(CD, Ctor_Complete);
}
}
CodeGenModule.cpp: [PR33810][Modules] Avoid reusing FoundStr to try to fix crash. MangledDeclNames might grow up and be reallocated when it were reused by reentering CodeGenModule::getMangledName(). llvm-svn: 309501
2017-07-30 13:06:26 +08:00
auto FoundName = MangledDeclNames.find(CanonicalGD);
if (FoundName != MangledDeclNames.end())
return FoundName->second;
Add a new variant of getMangledName that caches the mangling for decls. llvm-svn: 106547
2010-06-23 00:05:32 +08:00
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
const auto *ND = cast<NamedDecl>(GD.getDecl());
SmallString<256> Buffer;
StringRef Str;
if (getCXXABI().getMangleContext().shouldMangleDeclName(ND)) {
llvm::raw_svector_ostream Out(Buffer);
if (const auto *D = dyn_cast<CXXConstructorDecl>(ND))
getCXXABI().getMangleContext().mangleCXXCtor(D, GD.getCtorType(), Out);
else if (const auto *D = dyn_cast<CXXDestructorDecl>(ND))
getCXXABI().getMangleContext().mangleCXXDtor(D, GD.getDtorType(), Out);
else
getCXXABI().getMangleContext().mangleName(ND, Out);
Str = Out.str();
} else {
Add a new variant of getMangledName that caches the mangling for decls. llvm-svn: 106547
2010-06-23 00:05:32 +08:00
IdentifierInfo *II = ND->getIdentifier();
assert(II && "Attempt to mangle unnamed decl.");
regcall: Implement regcall Calling Conv in clang This patch implements the register call calling convention, which ensures as many values as possible are passed in registers. CodeGen changes were committed in https://reviews.llvm.org/rL284108. Differential Revision: https://reviews.llvm.org/D25204 llvm-svn: 285849
2016-11-03 02:29:35 +08:00
const auto *FD = dyn_cast<FunctionDecl>(ND);
if (FD &&
FD->getType()->castAs<FunctionType>()->getCallConv() == CC_X86RegCall) {
llvm::raw_svector_ostream Out(Buffer);
Out << "__regcall3__" << II->getName();
Str = Out.str();
} else {
Str = II->getName();
}
Add a new variant of getMangledName that caches the mangling for decls. llvm-svn: 106547
2010-06-23 00:05:32 +08:00
}
In the case of mangling collisions, make an attempt to note both definitions involved. llvm-svn: 214606
2014-08-02 08:50:16 +08:00
// Keep the first result in the case of a mangling collision.
auto Result = Manglings.insert(std::make_pair(Str, GD));
CodeGenModule.cpp: [PR33810][Modules] Avoid reusing FoundStr to try to fix crash. MangledDeclNames might grow up and be reallocated when it were reused by reentering CodeGenModule::getMangledName(). llvm-svn: 309501
2017-07-30 13:06:26 +08:00
return MangledDeclNames[CanonicalGD] = Result.first->first();
Add a new variant of getMangledName that caches the mangling for decls. llvm-svn: 106547
2010-06-23 00:05:32 +08:00
}
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
StringRef CodeGenModule::getBlockMangledName(GlobalDecl GD,
const BlockDecl *BD) {
Move name mangling support from CodeGen to AST. In the process, perform a number of refactorings: - Move MiscNameMangler member functions to MangleContext - Remove GlobalDecl dependency from MangleContext - Make MangleContext abstract and move Itanium/Microsoft functionality to their own classes/files - Implement ASTContext::createMangleContext and have CodeGen use it No (intended) functionality change. llvm-svn: 123386
2011-01-14 02:57:25 +08:00
MangleContext &MangleCtx = getCXXABI().getMangleContext();
const Decl *D = GD.getDecl();
Eliminate redundant MangleBuffer class The only remaining user didn't actually use the non-dynamic storage facility this class provides. The std::string is transitional and likely to be StringRefized shortly. llvm-svn: 210058
2014-06-03 10:13:57 +08:00
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
SmallString<256> Buffer;
llvm::raw_svector_ostream Out(Buffer);
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
if (!D)
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
MangleCtx.mangleGlobalBlock(BD,
block literal irgen: several improvements on naming block literal helper functions. All helper functions (global and locals) use block_invoke as their prefix. Local literal helper names are prefixed by their enclosing mangled function names. Blocks in non-local initializers (e.g. a global variable or a C++11 field) are prefixed by their mangled variable name. The descriminator number added to end of the name starts off with blank (for first block) and _<N> (for the N+2-th block). llvm-svn: 159206
2012-06-27 00:06:38 +08:00
dyn_cast_or_null<VarDecl>(initializedGlobalDecl.getDecl()), Out);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
else if (const auto *CD = dyn_cast<CXXConstructorDecl>(D))
Use raw_svector_ostream in more places in the mangler. llvm-svn: 125321
2011-02-11 07:59:36 +08:00
MangleCtx.mangleCtorBlock(CD, GD.getCtorType(), BD, Out);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
else if (const auto *DD = dyn_cast<CXXDestructorDecl>(D))
Use raw_svector_ostream in more places in the mangler. llvm-svn: 125321
2011-02-11 07:59:36 +08:00
MangleCtx.mangleDtorBlock(DD, GD.getDtorType(), BD, Out);
Move name mangling support from CodeGen to AST. In the process, perform a number of refactorings: - Move MiscNameMangler member functions to MangleContext - Remove GlobalDecl dependency from MangleContext - Make MangleContext abstract and move Itanium/Microsoft functionality to their own classes/files - Implement ASTContext::createMangleContext and have CodeGen use it No (intended) functionality change. llvm-svn: 123386
2011-01-14 02:57:25 +08:00
else
Use raw_svector_ostream in more places in the mangler. llvm-svn: 125321
2011-02-11 07:59:36 +08:00
MangleCtx.mangleBlock(cast<DeclContext>(D), BD, Out);
Eliminate redundant MangleBuffer class The only remaining user didn't actually use the non-dynamic storage facility this class provides. The std::string is transitional and likely to be StringRefized shortly. llvm-svn: 210058
2014-06-03 10:13:57 +08:00
In the case of mangling collisions, make an attempt to note both definitions involved. llvm-svn: 214606
2014-08-02 08:50:16 +08:00
auto Result = Manglings.insert(std::make_pair(Out.str(), BD));
return Result.first->first();
Get rid of getMangledCXXCtorName and getMangledCXXDtorName. llvm-svn: 105673
2010-06-09 10:36:32 +08:00
}
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
llvm::GlobalValue *CodeGenModule::GetGlobalValue(StringRef Name) {
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
return getModule().getNamedValue(Name);
Add basic support for C++ name mangling according to the Itanium C++ ABI to the CodeGen library. Since C++ code-generation is so incomplete, we can't exercise much of this mangling code. However, a few smoke tests show that it's doing the same thing as GCC. When C++ codegen matures, we'll extend the ABI tester to verify name-mangling as well, and complete the implementation here. At this point, the major client of name mangling is in the uses of the new "overloadable" attribute in C, which allows overloading. Any "overloadable" function in C (or in an extern "C" block in C++) will be mangled the same way that the corresponding C++ function would be mangled. llvm-svn: 64413
2009-02-13 08:10:09 +08:00
}
add initial support for generating an llvm.globalctors list. Patch by David Chisnall llvm-svn: 48362
2008-03-15 01:18:18 +08:00
/// AddGlobalCtor - Add a function to the list that will be called before
/// main() runs.
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
void CodeGenModule::AddGlobalCtor(llvm::Function *Ctor, int Priority,
llvm::Constant *AssociatedData) {
Bug fix, __private_extern__ globals were always introducing a definition. llvm-svn: 62139
2009-01-13 10:25:00 +08:00
// FIXME: Type coercion of void()* types.
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
GlobalCtors.push_back(Structor(Priority, Ctor, AssociatedData));
add initial support for generating an llvm.globalctors list. Patch by David Chisnall llvm-svn: 48362
2008-03-15 01:18:18 +08:00
}
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
/// AddGlobalDtor - Add a function to the list that will be called
/// when the module is unloaded.
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
void CodeGenModule::AddGlobalDtor(llvm::Function *Dtor, int Priority) {
Bug fix, __private_extern__ globals were always introducing a definition. llvm-svn: 62139
2009-01-13 10:25:00 +08:00
// FIXME: Type coercion of void()* types.
[C++11] Use 'nullptr'. llvm-svn: 210448
2014-06-09 10:04:02 +08:00
GlobalDtors.push_back(Structor(Priority, Dtor, nullptr));
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
}
Empty the CtorLists/DtorLists once emitted. This is essential when clang is running in incremental processing mode because we don't want to reemit the 'tors over and over again. Patch by Axel Naumann! Reviewed by Richard Smith and me. (https://reviews.llvm.org/D25605) llvm-svn: 285277
2016-10-27 17:12:20 +08:00
void CodeGenModule::EmitCtorList(CtorList &Fns, const char *GlobalName) {
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
if (Fns.empty()) return;
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
// Ctor function type is void()*.
Use arrays and SmallVectors instead of std::vectors when building function types. Also, cache a translation of 'void' in CGM and provide a ptrdiff_t alias. No functionality change. llvm-svn: 131373
2011-05-15 09:53:33 +08:00
llvm::FunctionType* CtorFTy = llvm::FunctionType::get(VoidTy, false);
Update for LLVM API change. llvm-svn: 77514
2009-07-30 06:16:19 +08:00
llvm::Type *CtorPFTy = llvm::PointerType::getUnqual(CtorFTy);
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
Use comdats to avoid double initialization of weak data Initializers of global data that can appear multiple TUs (static data members of class templates or __declspec(selectany) data) are now in a comdat group keyed on the global variable being initialized. On non-Windows platforms, this is a code size and startup time optimization. On Windows, this is necessary for ABI compatibility with MSVC. Fixes PR16959. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3811 llvm-svn: 209555
2014-05-24 05:13:45 +08:00
// Get the type of a ctor entry, { i32, void ()*, i8* }.
llvm::StructType *CtorStructTy = llvm::StructType::get(
Suppress all uses of LLVM_END_WITH_NULL. NFC. Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential revision: https://reviews.llvm.org/D32550 llvm-svn: 302572
2017-05-10 03:31:30 +08:00
Int32Ty, llvm::PointerType::getUnqual(CtorFTy), VoidPtrTy);
Support constructor and destructor attributes in CodeGen - There is an miscompilation issue remaining due to a poor interaction between the delayed emission of static functions and the emission of constructors, but that already existed prior to this change. llvm-svn: 54258
2008-08-01 08:01:51 +08:00
// Construct the constructor and destructor arrays.
ConstantBuilder -> ConstantInitBuilder for clarity, and move the member classes up to top level to allow forward declarations to name them. NFC. llvm-svn: 288079
2016-11-29 06:18:27 +08:00
ConstantInitBuilder builder(*this);
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
auto ctors = builder.beginArray(CtorStructTy);
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (const auto &I : Fns) {
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
auto ctor = ctors.beginStruct(CtorStructTy);
ctor.addInt(Int32Ty, I.Priority);
ctor.add(llvm::ConstantExpr::getBitCast(I.Initializer, CtorPFTy));
if (I.AssociatedData)
ctor.add(llvm::ConstantExpr::getBitCast(I.AssociatedData, VoidPtrTy));
else
ctor.addNullPointer(VoidPtrTy);
Hide the result of building a constant initializer. NFC. llvm-svn: 288080
2016-11-29 06:18:30 +08:00
ctor.finishAndAddTo(ctors);
add initial support for generating an llvm.globalctors list. Patch by David Chisnall llvm-svn: 48362
2008-03-15 01:18:18 +08:00
}
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
Remove alignment from ctors/dtors lists in an attempt to placate LTO. llvm-svn: 287458
2016-11-20 04:12:25 +08:00
auto list =
ctors.finishAndCreateGlobal(GlobalName, getPointerAlign(),
/*constant*/ false,
llvm::GlobalValue::AppendingLinkage);
// The LTO linker doesn't seem to like it when we set an alignment
// on appending variables. Take it off as a workaround.
list->setAlignment(0);
Empty the CtorLists/DtorLists once emitted. This is essential when clang is running in incremental processing mode because we don't want to reemit the 'tors over and over again. Patch by Axel Naumann! Reviewed by Richard Smith and me. (https://reviews.llvm.org/D25605) llvm-svn: 285277
2016-10-27 17:12:20 +08:00
Fns.clear();
add initial support for generating an llvm.globalctors list. Patch by David Chisnall llvm-svn: 48362
2008-03-15 01:18:18 +08:00
}
Re-introduce the ctor/dtor alias optimization, this time hidden behind a command-line option which defaults off. llvm-svn: 96649
2010-02-19 09:32:20 +08:00
llvm::GlobalValue::LinkageTypes
[ms-cxxabi] Thread GlobalDecls through to CodeGenModule::getFunctionLinkage. This is so that we can give destructor variants different linkage later. Differential Revision: http://llvm-reviews.chandlerc.com/D819 llvm-svn: 183324
2013-06-06 01:49:37 +08:00
CodeGenModule::getFunctionLinkage(GlobalDecl GD) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *D = cast<FunctionDecl>(GD.getDecl());
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
Merge PCHWriterDecl.cpp's isRequiredDecl and CodeGenModule::MayDeferGeneration into a new function, DeclIsRequiredFunctionOrFileScopedVar. This is essentially a CodeGen predicate that is also needed by the PCH mechanism to determine whether a decl needs to be deserialized during PCH loading for codegen purposes. Since this logic is shared by CodeGen and the PCH mechanism, move it to the ASTContext, thus CodeGenModule's GetLinkageForFunction/GetLinkageForVariable and the GVALinkage enum is moved out of CodeGen. This fixes current (and avoids future) codegen-from-PCH bugs. llvm-svn: 109784
2010-07-30 02:15:58 +08:00
GVALinkage Linkage = getContext().GetGVALinkageForFunction(D);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
Don't dllimport/export destructor variants implemented by thunks. MSVC doesn't export these functions, so trying to import them doesnt' work. Also, don't let any dll attributes on the CXXDestructorDecl influence the thunk's linkage -- they should always be linkonce_odr. This takes care of the FIXME's for this in Nico's tests. Differential Revision: http://reviews.llvm.org/D3930 llvm-svn: 209706
2014-05-28 09:52:23 +08:00
if (isa<CXXDestructorDecl>(D) &&
[ms-cxxabi] Fix linkage of dtor thunks for anonymous classes We were mistakengly giving linkonce_odr linkage instead of internal linkage to the deleting and complete destructor thunks for classes in anonymous namespaces. Fixes PR17273. llvm-svn: 197060
2013-12-12 03:21:27 +08:00
getCXXABI().useThunkForDtorVariant(cast<CXXDestructorDecl>(D),
Don't dllimport/export destructor variants implemented by thunks. MSVC doesn't export these functions, so trying to import them doesnt' work. Also, don't let any dll attributes on the CXXDestructorDecl influence the thunk's linkage -- they should always be linkonce_odr. This takes care of the FIXME's for this in Nico's tests. Differential Revision: http://reviews.llvm.org/D3930 llvm-svn: 209706
2014-05-28 09:52:23 +08:00
GD.getDtorType())) {
// Destructor variants in the Microsoft C++ ABI are always internal or
// linkonce_odr thunks emitted on an as-needed basis.
return Linkage == GVA_Internal ? llvm::GlobalValue::InternalLinkage
: llvm::GlobalValue::LinkOnceODRLinkage;
}
[ms-cxxabi] Fix linkage of dtor thunks for anonymous classes We were mistakengly giving linkonce_odr linkage instead of internal linkage to the deleting and complete destructor thunks for classes in anonymous namespaces. Fixes PR17273. llvm-svn: 197060
2013-12-12 03:21:27 +08:00
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
2016-06-29 03:03:57 +08:00
if (isa<CXXConstructorDecl>(D) &&
cast<CXXConstructorDecl>(D)->isInheritingConstructor() &&
Context.getTargetInfo().getCXXABI().isMicrosoft()) {
// Our approach to inheriting constructors is fundamentally different from
// that used by the MS ABI, so keep our inheriting constructor thunks
// internal rather than trying to pick an unambiguous mangling for them.
return llvm::GlobalValue::InternalLinkage;
}
Don't dllimport/export destructor variants implemented by thunks. MSVC doesn't export these functions, so trying to import them doesnt' work. Also, don't let any dll attributes on the CXXDestructorDecl influence the thunk's linkage -- they should always be linkonce_odr. This takes care of the FIXME's for this in Nico's tests. Differential Revision: http://reviews.llvm.org/D3930 llvm-svn: 209706
2014-05-28 09:52:23 +08:00
return getLLVMLinkageForDeclarator(D, Linkage, /*isConstantVariable=*/false);
Re-introduce the ctor/dtor alias optimization, this time hidden behind a command-line option which defaults off. llvm-svn: 96649
2010-02-19 09:32:20 +08:00
}
implement the alias attirbute (in both Sema and Codegen) llvm-svn: 52092
2008-06-08 23:45:52 +08:00
Get the dll storage class right for structors of classes exported/imported via explicit instantiation (PR23667) This is a follow-up to r238266. It turned out structors are codegened through a different path, and didn't get the storage class set in EmitGlobalFunctionDefinition. llvm-svn: 238443
2015-05-29 01:44:56 +08:00
void CodeGenModule::setFunctionDLLStorageClass(GlobalDecl GD, llvm::Function *F) {
const auto *FD = cast<FunctionDecl>(GD.getDecl());
if (const auto *Dtor = dyn_cast_or_null<CXXDestructorDecl>(FD)) {
if (getCXXABI().useThunkForDtorVariant(Dtor, GD.getDtorType())) {
// Don't dllexport/import destructor thunks.
F->setDLLStorageClass(llvm::GlobalValue::DefaultStorageClass);
return;
}
}
if (FD->hasAttr<DLLImportAttr>())
F->setDLLStorageClass(llvm::GlobalVariable::DLLImportStorageClass);
else if (FD->hasAttr<DLLExportAttr>())
F->setDLLStorageClass(llvm::GlobalVariable::DLLExportStorageClass);
else
F->setDLLStorageClass(llvm::GlobalVariable::DefaultStorageClass);
}
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
llvm::ConstantInt *CodeGenModule::CreateCrossDsoCfiTypeId(llvm::Metadata *MD) {
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
llvm::MDString *MDS = dyn_cast<llvm::MDString>(MD);
if (!MDS) return nullptr;
[CodeGen] Simplify code. No functionality change intended. llvm-svn: 287754
2016-11-23 19:20:27 +08:00
return llvm::ConstantInt::get(Int64Ty, llvm::MD5Hash(MDS->getString()));
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
}
Cleanup setFunctionDefinitionAttributes. Use more specific type, update comments and name style. llvm-svn: 208328
2014-05-08 23:26:12 +08:00
void CodeGenModule::setFunctionDefinitionAttributes(const FunctionDecl *D,
llvm::Function *F) {
setNonAliasAttributes(D, F);
implement the alias attirbute (in both Sema and Codegen) llvm-svn: 52092
2008-06-08 23:45:52 +08:00
}
Rename (one) SetFunctionAttributes to SetLLVMFunctionAttributes to disambiguate it. - No functionality change. llvm-svn: 69034
2009-04-14 15:08:30 +08:00
void CodeGenModule::SetLLVMFunctionAttributes(const Decl *D,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
const CGFunctionInfo &Info,
Rename (one) SetFunctionAttributes to SetLLVMFunctionAttributes to disambiguate it. - No functionality change. llvm-svn: 69034
2009-04-14 15:08:30 +08:00
llvm::Function *F) {
Change CodeGenModule::ConstructTypeAttributes to return the calling convention to use, and allow the ABI implementation to override the calling convention. llvm-svn: 81593
2009-09-12 08:59:20 +08:00
unsigned CallingConv;
Use less temporary AttributeLists NFC llvm-svn: 300628
2017-04-19 07:50:03 +08:00
llvm::AttributeList PAL;
ConstructAttributeList(F->getName(), Info, D, PAL, CallingConv, false);
F->setAttributes(PAL);
Change CodeGenModule::ConstructTypeAttributes to return the calling convention to use, and allow the ABI implementation to override the calling convention. llvm-svn: 81593
2009-09-12 08:59:20 +08:00
F->setCallingConv(static_cast<llvm::CallingConv::ID>(CallingConv));
Set function attributes (sext, zext, etc.) on Objective-C methods. llvm-svn: 55812
2008-09-05 07:41:35 +08:00
}
Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
/// Determines whether the language options require us to model
/// unwind exceptions. We treat -fexceptions as mandating this
/// except under the fragile ObjC ABI with only ObjC exceptions
/// enabled. This means, for example, that C with -fexceptions
/// enables this.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
static bool hasUnwindExceptions(const LangOptions &LangOpts) {
Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
// If exceptions are completely disabled, obviously this is false.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (!LangOpts.Exceptions) return false;
Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
// If C++ exceptions are enabled, this is true.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.CXXExceptions) return true;
Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
// If ObjC exceptions are enabled, this depends on the ABI.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.ObjCExceptions) {
Rename the GCC Objective-C runtime to gcc from gnu-fragile and the GNUstep runtime to gnustep from gnu. Fix EH for the GCC runtime. llvm-svn: 159684
2012-07-04 04:49:52 +08:00
return LangOpts.ObjCRuntime.hasUnwindExceptions();
Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
}
return true;
}
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
void CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
llvm::Function *F) {
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
llvm::AttrBuilder B;
Update for llvm api change. llvm-svn: 132034
2011-05-25 11:44:55 +08:00
if (CodeGenOpts.UnwindTables)
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
B.addAttribute(llvm::Attribute::UWTable);
Update for llvm api change. llvm-svn: 132034
2011-05-25 11:44:55 +08:00
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (!hasUnwindExceptions(LangOpts))
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
B.addAttribute(llvm::Attribute::NoUnwind);
Add attribute always_inline support. llvm-svn: 58304
2008-10-28 08:17:57 +08:00
[CodeGen] Check if the Decl pointer passed is null, and if so, return early. This is needed in a patch I plan to commit later, in which a null Decl pointer is passed to SetLLVMFunctionAttributesForDefinition. Relevant discussion is in http://reviews.llvm.org/D13525. llvm-svn: 249722
2015-10-09 03:30:57 +08:00
if (LangOpts.getStackProtector() == LangOptions::SSPOn)
B.addAttribute(llvm::Attribute::StackProtect);
else if (LangOpts.getStackProtector() == LangOptions::SSPStrong)
B.addAttribute(llvm::Attribute::StackProtectStrong);
else if (LangOpts.getStackProtector() == LangOptions::SSPReq)
B.addAttribute(llvm::Attribute::StackProtectReq);
if (!D) {
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
// If we don't have a declaration to control inlining, the function isn't
// explicitly marked as alwaysinline for semantic reasons, and inlining is
// disabled, mark the function as noinline.
if (!F->hasFnAttribute(llvm::Attribute::AlwaysInline) &&
CodeGenOpts.getInlining() == CodeGenOptions::OnlyAlwaysInlining)
B.addAttribute(llvm::Attribute::NoInline);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
F->addAttributes(llvm::AttributeList::FunctionIndex, B);
[CodeGen] Check if the Decl pointer passed is null, and if so, return early. This is needed in a patch I plan to commit later, in which a null Decl pointer is passed to SetLLVMFunctionAttributesForDefinition. Relevant discussion is in http://reviews.llvm.org/D13525. llvm-svn: 249722
2015-10-09 03:30:57 +08:00
return;
}
IRGen: Add optnone attribute on function during O0 Amongst other, this will help LTO to correctly handle/honor files compiled with O0, helping debugging failures. It also seems in line with how we handle other options, like how -fnoinline adds the appropriate attribute as well. Differential Revision: https://reviews.llvm.org/D28404 llvm-svn: 304127
2017-05-29 13:38:20 +08:00
// Track whether we need to add the optnone LLVM attribute,
// starting with the default for this optimization level.
bool ShouldAddOptNone =
!CodeGenOpts.DisableO0ImplyOptNone && CodeGenOpts.OptimizationLevel == 0;
// We can't add optnone in the following cases, it won't pass the verifier.
ShouldAddOptNone &= !D->hasAttr<MinSizeAttr>();
ShouldAddOptNone &= !F->hasFnAttribute(llvm::Attribute::AlwaysInline);
ShouldAddOptNone &= !D->hasAttr<AlwaysInlineAttr>();
if (ShouldAddOptNone || D->hasAttr<OptimizeNoneAttr>()) {
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
B.addAttribute(llvm::Attribute::OptimizeNone);
// OptimizeNone implies noinline; we should not be inlining such functions.
B.addAttribute(llvm::Attribute::NoInline);
assert(!F->hasFnAttribute(llvm::Attribute::AlwaysInline) &&
"OptimizeNone and AlwaysInline on same function!");
// We still need to handle naked functions even though optnone subsumes
// much of their semantics.
if (D->hasAttr<NakedAttr>())
B.addAttribute(llvm::Attribute::Naked);
// OptimizeNone wins over OptimizeForSize and MinSize.
F->removeFnAttr(llvm::Attribute::OptimizeForSize);
F->removeFnAttr(llvm::Attribute::MinSize);
} else if (D->hasAttr<NakedAttr>()) {
Make sure we don't inline functions marked with __attribute__((naked)). <rdar://problem/9973228> llvm-svn: 138310
2011-08-23 07:55:33 +08:00
// Naked implies noinline: we should not be inlining such functions.
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
B.addAttribute(llvm::Attribute::Naked);
B.addAttribute(llvm::Attribute::NoInline);
Exposing the noduplicate attribute within Clang, which marks functions so that the optimizer does not duplicate code. Patch thanks to Marcello Maggioni! llvm-svn: 201941
2014-02-23 00:59:24 +08:00
} else if (D->hasAttr<NoDuplicateAttr>()) {
B.addAttribute(llvm::Attribute::NoDuplicate);
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
} else if (D->hasAttr<NoInlineAttr>()) {
B.addAttribute(llvm::Attribute::NoInline);
Attr: Remove ForceInline The __forceinline keyword's semantics are now recast as AlwaysInline and the kw___forceinline token has its language mode set for KEYMS. This preserves the semantics of the previous implementation but with less duplication of code. llvm-svn: 202131
2014-02-25 17:53:29 +08:00
} else if (D->hasAttr<AlwaysInlineAttr>() &&
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
!F->hasFnAttribute(llvm::Attribute::NoInline)) {
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
// (noinline wins over always_inline, and we can't specify both in IR)
Revert "Always_inline codegen rewrite" and 2 follow-ups. Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
2015-09-15 05:35:16 +08:00
B.addAttribute(llvm::Attribute::AlwaysInline);
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
} else if (CodeGenOpts.getInlining() == CodeGenOptions::OnlyAlwaysInlining) {
// If we're not inlining, then force everything that isn't always_inline to
// carry an explicit noinline attribute.
if (!F->hasFnAttribute(llvm::Attribute::AlwaysInline))
B.addAttribute(llvm::Attribute::NoInline);
} else {
// Otherwise, propagate the inline hint attribute and potentially use its
// absence to mark things as noinline.
if (auto *FD = dyn_cast<FunctionDecl>(D)) {
if (any_of(FD->redecls(), [&](const FunctionDecl *Redecl) {
return Redecl->isInlineSpecified();
})) {
B.addAttribute(llvm::Attribute::InlineHint);
} else if (CodeGenOpts.getInlining() ==
CodeGenOptions::OnlyHintInlining &&
!FD->isInlined() &&
!F->hasFnAttribute(llvm::Attribute::AlwaysInline)) {
B.addAttribute(llvm::Attribute::NoInline);
}
}
Make sure we don't inline functions marked with __attribute__((naked)). <rdar://problem/9973228> llvm-svn: 138310
2011-08-23 07:55:33 +08:00
}
Add support for attribute((naked)), patch by Zoxc on cfe-commits! - Minor style tweaks by me. llvm-svn: 115056
2010-09-30 02:20:25 +08:00
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
// Add other optimization related attributes if we are optimizing this
// function.
if (!D->hasAttr<OptimizeNoneAttr>()) {
if (D->hasAttr<ColdAttr>()) {
IRGen: Add optnone attribute on function during O0 Amongst other, this will help LTO to correctly handle/honor files compiled with O0, helping debugging failures. It also seems in line with how we handle other options, like how -fnoinline adds the appropriate attribute as well. Differential Revision: https://reviews.llvm.org/D28404 llvm-svn: 304127
2017-05-29 13:38:20 +08:00
if (!ShouldAddOptNone)
B.addAttribute(llvm::Attribute::OptimizeForSize);
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
B.addAttribute(llvm::Attribute::Cold);
}
Add support for __attribute__((hot)) and __attribute__((cold)). Currently cold functions are marked with the "optsize" attribute in CodeGen so they are always optimized for size. The hot attribute is just ignored, LLVM doesn't have a way to express hotness at the moment. llvm-svn: 156723
2012-05-13 05:10:52 +08:00
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
if (D->hasAttr<MinSizeAttr>())
B.addAttribute(llvm::Attribute::MinSize);
}
PR13941: Mark all virtual functions as unnamed_addr. It's not possible to observe their addresses (taking their address gives the vtable slot) so we are free to merge their definitions. llvm-svn: 164864
2012-09-29 06:46:07 +08:00
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
F->addAttributes(llvm::AttributeList::FunctionIndex, B);
CodeGen: Refactor SetLLVMFunctionAttributesForDefinition to use an AttrBuilder. Adding attributes to a uniqued set has become expensive, don't do it more often than necessary. No functionality change. llvm-svn: 181662
2013-05-11 20:45:37 +08:00
Generate Attr subclasses with TableGen. Now all classes derived from Attr are generated from TableGen. Additionally, Attr* is no longer its own linked list; SmallVectors or Attr* are used. The accompanying LLVM commit contains the updates to TableGen necessary for this. Some other notes about newly-generated attribute classes: - The constructor arguments are a SourceLocation and a Context&, followed by the attributes arguments in the order that they were defined in Attr.td - Every argument in Attr.td has an appropriate accessor named getFoo, and there are sometimes a few extra ones (such as to get the length of a variadic argument). Additionally, specific_attr_iterator has been introduced, which will iterate over an AttrVec, but only over attributes of a certain type. It can be accessed through either Decl::specific_attr_begin/end or the global functions of the same name. llvm-svn: 111455
2010-08-19 07:23:40 +08:00
unsigned alignment = D->getMaxAlignment() / Context.getCharWidth();
if (alignment)
F->setAlignment(alignment);
[WebAssembly] Initial WebAssembly support in clang This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet finalized, and may change. Differential Revision: http://reviews.llvm.org/D12002 llvm-svn: 246814
2015-09-04 06:51:53 +08:00
// Some C++ ABIs require 2-byte alignment for member functions, in order to
// reserve a bit for differentiating between virtual and non-virtual member
// functions. If the current target's C++ ABI requires this and this is a
// member function, set its alignment accordingly.
if (getTarget().getCXXABI().areMemberFunctionsAligned()) {
if (F->getAlignment() < 2 && isa<CXXMethodDecl>(D))
F->setAlignment(2);
}
[cfi] Fix missing !type annotation. CFI (only in the cross-dso mode) fails to set !type annotations when a function is used before it is defined. llvm-svn: 285650
2016-11-01 06:28:10 +08:00
// In the cross-dso CFI mode, we want !type attributes on definitions only.
if (CodeGenOpts.SanitizeCfiCrossDso)
if (auto *FD = dyn_cast<FunctionDecl>(D))
CreateFunctionTypeMetadata(FD, F);
Set function attributes (sext, zext, etc.) on Objective-C methods. llvm-svn: 55812
2008-09-05 07:41:35 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
void CodeGenModule::SetCommonAttributes(const Decl *D,
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
llvm::GlobalValue *GV) {
[CodeGen] [CodeGen] Attach function attributes to functions created in CGBlocks.cpp. This commit fixes a bug in clang's code-gen where it creates the following functions but doesn't attach function attributes to them: __copy_helper_block_ __destroy_helper_block_ __Block_byref_object_copy_ __Block_byref_object_dispose_ rdar://problem/20828324 Differential Revision: http://reviews.llvm.org/D13525 llvm-svn: 249735
2015-10-09 04:26:34 +08:00
if (const auto *ND = dyn_cast_or_null<NamedDecl>(D))
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
setGlobalVisibility(GV, ND, ForDefinition);
Substantially revise how clang computes the visibility of a declaration to more closely parallel the computation of linkage. This gets us to a state much closer to what gcc emits, modulo bugs, which will undoubtedly arise in abundance. llvm-svn: 117147
2010-10-23 05:05:15 +08:00
else
GV->setVisibility(llvm::GlobalValue::DefaultVisibility);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
[CodeGen] [CodeGen] Attach function attributes to functions created in CGBlocks.cpp. This commit fixes a bug in clang's code-gen where it creates the following functions but doesn't attach function attributes to them: __copy_helper_block_ __destroy_helper_block_ __Block_byref_object_copy_ __Block_byref_object_dispose_ rdar://problem/20828324 Differential Revision: http://reviews.llvm.org/D13525 llvm-svn: 249735
2015-10-09 04:26:34 +08:00
if (D && D->hasAttr<UsedAttr>())
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
addUsedGlobal(GV);
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
}
Fix ctor/dtor aliases losing 'dllexport' (for Itanium ABI) This patch makes sure that the dllexport attribute is transferred to the alias when such alias is created. It only affects the Itanium ABI because for the MSVC ABI a workaround is in place to not generate aliases of dllexport ctors/dtors. A new CodeGenModule function is provided, CodeGenModule::setAliasAttributes, to factor the code for transferring attributes to aliases. llvm-svn: 218159
2014-09-20 06:06:24 +08:00
void CodeGenModule::setAliasAttributes(const Decl *D,
llvm::GlobalValue *GV) {
SetCommonAttributes(D, GV);
// Process the dllexport attribute based on whether the original definition
// (not necessarily the aliasee) was exported.
if (D->hasAttr<DLLExportAttr>())
GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
}
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
void CodeGenModule::setNonAliasAttributes(const Decl *D,
Update for llvm API change. llvm-svn: 208717
2014-05-14 02:45:53 +08:00
llvm::GlobalObject *GO) {
SetCommonAttributes(D, GO);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
Add support for #pragma clang section This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
2017-06-05 18:11:57 +08:00
if (D) {
if (auto *GV = dyn_cast<llvm::GlobalVariable>(GO)) {
if (auto *SA = D->getAttr<PragmaClangBSSSectionAttr>())
GV->addAttribute("bss-section", SA->getName());
if (auto *SA = D->getAttr<PragmaClangDataSectionAttr>())
GV->addAttribute("data-section", SA->getName());
if (auto *SA = D->getAttr<PragmaClangRodataSectionAttr>())
GV->addAttribute("rodata-section", SA->getName());
}
if (auto *F = dyn_cast<llvm::Function>(GO)) {
if (auto *SA = D->getAttr<PragmaClangTextSectionAttr>())
if (!D->getAttr<SectionAttr>())
F->addFnAttr("implicit-section-name", SA->getName());
}
[CodeGen] [CodeGen] Attach function attributes to functions created in CGBlocks.cpp. This commit fixes a bug in clang's code-gen where it creates the following functions but doesn't attach function attributes to them: __copy_helper_block_ __destroy_helper_block_ __Block_byref_object_copy_ __Block_byref_object_dispose_ rdar://problem/20828324 Differential Revision: http://reviews.llvm.org/D13525 llvm-svn: 249735
2015-10-09 04:26:34 +08:00
if (const SectionAttr *SA = D->getAttr<SectionAttr>())
GO->setSection(SA->getName());
Add support for #pragma clang section This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
2017-06-05 18:11:57 +08:00
}
Generalize target weirdness handling having proper layering in mind: 1. Add helper class for sema checks for target attributes 2. Add helper class for codegen of target attributes As a proof-of-concept - implement msp430's 'interrupt' attribute. llvm-svn: 93118
2010-01-10 20:58:08 +08:00
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
getTargetCodeGenInfo().setTargetAttributes(D, GO, *this, ForDefinition);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
}
Attributes on block functions were not being set. - <rdar://problem/6800351> clang not producing correct large struct return code for Blocks llvm-svn: 69337
2009-04-17 08:48:04 +08:00
void CodeGenModule::SetInternalFunctionAttributes(const Decl *D,
llvm::Function *F,
const CGFunctionInfo &FI) {
SetLLVMFunctionAttributes(D, FI, F);
SetLLVMFunctionAttributesForDefinition(D, F);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
F->setLinkage(llvm::Function::InternalLinkage);
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
setNonAliasAttributes(D, F);
Set function attributes (sext, zext, etc.) on Objective-C methods. llvm-svn: 55812
2008-09-05 07:41:35 +08:00
}
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
static void setLinkageForGV(llvm::GlobalValue *GV,
const NamedDecl *ND) {
CodeGen: Refactor linkage/visibility calculation It turns out that linkage and visibility have rather similar logic for both functions and non-variable globals. Split the calculation out so that both sides may share this code. No functionality change. llvm-svn: 207239
2014-04-26 01:07:16 +08:00
// Set linkage and visibility in case we never see a definition.
LinkageInfo LV = ND->getLinkageAndVisibility();
[modules ts] Basic for module linkage. In addition to the formal linkage rules, the Modules TS includes cases where internal-linkage symbols within a module interface unit can be referenced from outside the module via exported inline functions / templates. We give such declarations "module-internal linkage", which is formally internal linkage, but results in an externally-visible symbol. llvm-svn: 307434
2017-07-08 04:04:28 +08:00
if (!isExternallyVisible(LV.getLinkage())) {
CodeGen: Refactor linkage/visibility calculation It turns out that linkage and visibility have rather similar logic for both functions and non-variable globals. Split the calculation out so that both sides may share this code. No functionality change. llvm-svn: 207239
2014-04-26 01:07:16 +08:00
// Don't set internal linkage on declarations.
} else {
if (ND->hasAttr<DLLImportAttr>()) {
GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
} else if (ND->hasAttr<DLLExportAttr>()) {
GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
} else if (ND->hasAttr<WeakAttr>() || ND->isWeakImported()) {
// "extern_weak" is overloaded in LLVM; we probably should have
// separate linkage types for this.
GV->setLinkage(llvm::GlobalValue::ExternalWeakLinkage);
}
}
}
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
void CodeGenModule::CreateFunctionTypeMetadata(const FunctionDecl *FD,
llvm::Function *F) {
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
// Only if we are checking indirect calls.
if (!LangOpts.Sanitize.has(SanitizerKind::CFIICall))
return;
// Non-static class methods are handled via vtable pointer checks elsewhere.
if (isa<CXXMethodDecl>(FD) && !cast<CXXMethodDecl>(FD)->isStatic())
return;
// Additionally, if building with cross-DSO support...
if (CodeGenOpts.SanitizeCfiCrossDso) {
// Skip available_externally functions. They won't be codegen'ed in the
// current module anyway.
if (getContext().GetGVALinkageForFunction(FD) == GVA_AvailableExternally)
return;
}
llvm::Metadata *MD = CreateMetadataIdentifierForType(FD->getType());
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
F->addTypeMetadata(0, MD);
[CFI] Add CFI-icall pointer type generalization Summary: This change allows generalizing pointers in type signatures used for cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag. This works by 1) emitting an additional generalized type signature metadata node for functions and 2) llvm.type.test()ing for the generalized type for translation units with the flag specified. This flag is incompatible with -fsanitize-cfi-cross-dso because it would require emitting twice as many type hashes which would increase artifact size. Reviewers: pcc, eugenis Reviewed By: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D39358 llvm-svn: 317044
2017-11-01 06:39:44 +08:00
F->addTypeMetadata(0, CreateMetadataIdentifierGeneralized(FD->getType()));
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
// Emit a hash-based bit set entry for cross-DSO calls.
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
if (CodeGenOpts.SanitizeCfiCrossDso)
if (auto CrossDsoTypeId = CreateCrossDsoCfiTypeId(MD))
F->addTypeMetadata(0, llvm::ConstantAsMetadata::get(CrossDsoTypeId));
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
}
CodeGen: Virtual dtor thunks shouldn't have this marked as 'returned' The ARM ABI virtual destructor thunks cannot be marked as 'returned' because they return undef. llvm-svn: 221042
2014-11-01 13:42:23 +08:00
void CodeGenModule::SetFunctionAttributes(GlobalDecl GD, llvm::Function *F,
bool IsIncompleteFunction,
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
bool IsThunk,
ForDefinition_t IsForDefinition) {
Use Intrinsic::ID instead of unsigned. NFC. This is after LLVM r237810 which made Function::getIntrinsicID() return an Intrinsic::ID. llvm-svn: 237811
2015-05-21 01:17:45 +08:00
if (llvm::Intrinsic::ID IID = F->getIntrinsicID()) {
If this is an intrinsic function, set the function's attributes to the intrinsic's attributes. llvm-svn: 129000
2011-04-06 20:29:04 +08:00
// If this is an intrinsic function, set the function's attributes
// to the intrinsic's attributes.
Use Intrinsic::ID instead of unsigned. NFC. This is after LLVM r237810 which made Function::getIntrinsicID() return an Intrinsic::ID. llvm-svn: 237811
2015-05-21 01:17:45 +08:00
F->setAttributes(llvm::Intrinsic::getAttributes(getLLVMContext(), IID));
If this is an intrinsic function, set the function's attributes to the intrinsic's attributes. llvm-svn: 129000
2011-04-06 20:29:04 +08:00
return;
}
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *FD = cast<FunctionDecl>(GD.getDecl());
Use the correct function info for constructors when applying function attributes. Fixes PR6245. llvm-svn: 95474
2010-02-06 10:44:09 +08:00
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
if (!IsIncompleteFunction) {
Whether an argument is required (in contrast with being an optional argument passed through the variadic ellipsis) potentially affects how we need to lower it. Propagate this information down to the various getFunctionInfo(...) overloads on CodeGenTypes. Furthermore, rename those overloads to clarify their distinct purposes, and make sure we're calling the right one in the right place. This has a nice side-effect of making it easier to construct a function type, since the 'variadic' bit is no longer separable. This shouldn't really change anything for our existing platforms, with one minor exception --- we should now call variadic ObjC methods with the ... in the "right place" (see the test case), which I guess matters for anyone running GNUStep on MIPS. Mostly it's just a substantial clean-up. llvm-svn: 150788
2012-02-17 11:33:10 +08:00
SetLLVMFunctionAttributes(FD, getTypes().arrangeGlobalDeclaration(GD), F);
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
// Setup target-specific attributes.
if (!IsForDefinition)
getTargetCodeGenInfo().setTargetAttributes(FD, F, *this,
NotForDefinition);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Disable this-return optimizations when targeting iOS 5 and earlier. Clang implements the part of the ARM ABI saying that certain functions (e.g., constructors and destructors) return "this", but Apple's version of gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with llvm-gcc, which means that clang cannot safely assume that code from the C++ runtime will correctly follow the ABI. It is also possible to run into this problem when linking with other libraries built with gcc or llvm-gcc. Even though there is no way to reliably detect that situation, it is most likely to come up when targeting older versions of iOS. Disabling the optimization for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably good chance of fixing the issue for other older libraries as well. <rdar://problem/16377159> llvm-svn: 205272
2014-04-01 09:38:16 +08:00
// Add the Returned attribute for "this", except for iOS 5 and earlier
// where substantial code, including the libstdc++ dylib, was compiled with
// GCC and does not actually return "this".
CodeGen: Virtual dtor thunks shouldn't have this marked as 'returned' The ARM ABI virtual destructor thunks cannot be marked as 'returned' because they return undef. llvm-svn: 221042
2014-11-01 13:42:23 +08:00
if (!IsThunk && getCXXABI().HasThisReturn(GD) &&
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
!(getTriple().isiOS() && getTriple().isOSVersionLT(6))) {
Restore r184205 and associated commits (after commit of r185290) This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs. llvm-svn: 185291
2013-07-01 04:40:16 +08:00
assert(!F->arg_empty() &&
F->arg_begin()->getType()
->canLosslesslyBitCastTo(F->getReturnType()) &&
"unexpected this return");
F->addAttribute(1, llvm::Attribute::Returned);
}
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
// Only a few attributes are set on declarations; these may later be
// overridden by a definition.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
setLinkageForGV(F, FD);
setGlobalVisibility(F, FD, NotForDefinition);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
Add support for #pragma clang section This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
2017-06-05 18:11:57 +08:00
if (FD->getAttr<PragmaClangTextSectionAttr>()) {
F->addFnAttr("implicit-section-name");
}
Remove the ASTContext parameter from the attribute-related methods of Decl. The implementations of these methods can Use Decl::getASTContext() to get the ASTContext. This commit touches a lot of files since call sites for these methods are everywhere. I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it. llvm-svn: 74501
2009-06-30 10:34:44 +08:00
if (const SectionAttr *SA = FD->getAttr<SectionAttr>())
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
F->setSection(SA->getName());
Tighten up the set of operator new/operator delete calls we're permitted to optimize, to follow the permissions granted in N3664. Under those rules, only calls generated by new-expressions and delete-expressions are permitted to be optimized, and direct calls to ::operator new and ::operator delete must be treated as normal calls. llvm-svn: 186799
2013-07-22 07:12:18 +08:00
Replace Sema-level implementation of -fassume-sane-operator-new with a CodeGen-level implementation. Instead of adding an attribute to clang's FunctionDecl, add the IR attribute directly. This means a module built with this flag is now compatible with code built without it and vice versa. This change also results in the 'noalias' attribute no longer being added to calls to operator new in the IR; it's now only added to the declaration. It also fixes a bug where we failed to add the attribute to the 'nothrow' versions (because we didn't implicitly declare them, there was no good time to inject a fake attribute). llvm-svn: 265728
2016-04-08 05:46:12 +08:00
if (FD->isReplaceableGlobalAllocationFunction()) {
// A replaceable global allocation function does not act like a builtin by
// default, only if it is invoked by a new-expression or delete-expression.
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
F->addAttribute(llvm::AttributeList::FunctionIndex,
Tighten up the set of operator new/operator delete calls we're permitted to optimize, to follow the permissions granted in N3664. Under those rules, only calls generated by new-expressions and delete-expressions are permitted to be optimized, and direct calls to ::operator new and ::operator delete must be treated as normal calls. llvm-svn: 186799
2013-07-22 07:12:18 +08:00
llvm::Attribute::NoBuiltin);
CFI: Introduce -fsanitize=cfi-icall flag. This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
2015-09-10 10:17:40 +08:00
Replace Sema-level implementation of -fassume-sane-operator-new with a CodeGen-level implementation. Instead of adding an attribute to clang's FunctionDecl, add the IR attribute directly. This means a module built with this flag is now compatible with code built without it and vice versa. This change also results in the 'noalias' attribute no longer being added to calls to operator new in the IR; it's now only added to the declaration. It also fixes a bug where we failed to add the attribute to the 'nothrow' versions (because we didn't implicitly declare them, there was no good time to inject a fake attribute). llvm-svn: 265728
2016-04-08 05:46:12 +08:00
// A sane operator new returns a non-aliasing pointer.
// FIXME: Also add NonNull attribute to the return value
// for the non-nothrow forms?
auto Kind = FD->getDeclName().getCXXOverloadedOperator();
if (getCodeGenOpts().AssumeSaneOperatorNew &&
(Kind == OO_New || Kind == OO_Array_New))
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
F->addAttribute(llvm::AttributeList::ReturnIndex,
Replace Sema-level implementation of -fassume-sane-operator-new with a CodeGen-level implementation. Instead of adding an attribute to clang's FunctionDecl, add the IR attribute directly. This means a module built with this flag is now compatible with code built without it and vice versa. This change also results in the 'noalias' attribute no longer being added to calls to operator new in the IR; it's now only added to the declaration. It also fixes a bug where we failed to add the attribute to the 'nothrow' versions (because we didn't implicitly declare them, there was no good time to inject a fake attribute). llvm-svn: 265728
2016-04-08 05:46:12 +08:00
llvm::Attribute::NoAlias);
}
CodeGen: Mark functions used in vtables as unnamed_addr. This marks virtual function declarations, as well as runtime library functions __cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as unnamed_addr. This will allow us to correctly form relative references to them from vtables in the relative vtable ABI. Differential Revision: http://reviews.llvm.org/D18071 llvm-svn: 263464
2016-03-15 02:41:59 +08:00
if (isa<CXXConstructorDecl>(FD) || isa<CXXDestructorDecl>(FD))
Update clang for D20348 Differential Revision: http://reviews.llvm.org/D20339 llvm-svn: 272710
2016-06-15 05:02:05 +08:00
F->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
CodeGen: Mark functions used in vtables as unnamed_addr. This marks virtual function declarations, as well as runtime library functions __cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as unnamed_addr. This will allow us to correctly form relative references to them from vtables in the relative vtable ABI. Differential Revision: http://reviews.llvm.org/D18071 llvm-svn: 263464
2016-03-15 02:41:59 +08:00
else if (const auto *MD = dyn_cast<CXXMethodDecl>(FD))
if (MD->isVirtual())
Update clang for D20348 Differential Revision: http://reviews.llvm.org/D20339 llvm-svn: 272710
2016-06-15 05:02:05 +08:00
F->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
CodeGen: Mark functions used in vtables as unnamed_addr. This marks virtual function declarations, as well as runtime library functions __cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as unnamed_addr. This will allow us to correctly form relative references to them from vtables in the relative vtable ABI. Differential Revision: http://reviews.llvm.org/D18071 llvm-svn: 263464
2016-03-15 02:41:59 +08:00
[cfi] Fix missing !type annotation. CFI (only in the cross-dso mode) fails to set !type annotations when a function is used before it is defined. llvm-svn: 285650
2016-11-01 06:28:10 +08:00
// Don't emit entries for function declarations in the cross-DSO mode. This
// is handled with better precision by the receiving DSO.
if (!CodeGenOpts.SanitizeCfiCrossDso)
CreateFunctionTypeMetadata(FD, F);
[OPENMP] Codegen `declare simd` for function declarations. Previously the attributes were emitted only for function definitions. Patch adds emission of the attributes for function declarations. llvm-svn: 320826
2017-12-16 00:28:31 +08:00
if (getLangOpts().OpenMP && FD->hasAttr<OMPDeclareSimdDeclAttr>())
getOpenMPRuntime().emitDeclareSimdFunction(FD, F);
Fix a number of issues w.r.t. emission of global for functions and aliases. - Attributes specific to a definition are only set when the definition is seen. - Alias generation is delayed until the end of the module; necessary since the alias may reference forward. - Fixes: PR2743, <rdr://6140807&6094512> - Improves: <rdr://6095112> (added XFAIL) Also, print module on verification failures. llvm-svn: 55966
2008-09-09 07:44:31 +08:00
}
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
void CodeGenModule::addUsedGlobal(llvm::GlobalValue *GV) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
assert(!GV->isDeclaration() &&
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
"Only globals with definition can force usage.");
Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238601
2015-05-30 03:42:19 +08:00
LLVMUsed.emplace_back(GV);
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
}
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
void CodeGenModule::addCompilerUsedGlobal(llvm::GlobalValue *GV) {
assert(!GV->isDeclaration() &&
"Only globals with definition can force usage.");
Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238601
2015-05-30 03:42:19 +08:00
LLVMCompilerUsed.emplace_back(GV);
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
}
static void emitUsed(CodeGenModule &CGM, StringRef Name,
Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC llvm-svn: 301815
2017-05-02 01:08:00 +08:00
std::vector<llvm::WeakTrackingVH> &List) {
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
// Don't create llvm.used if there is no need.
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
if (List.empty())
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
return;
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
// Convert List to what ConstantArray needs.
use cheaper llvm APIs for various bits of IR generation. llvm-svn: 149916
2012-02-07 06:16:34 +08:00
SmallVector<llvm::Constant*, 8> UsedArray;
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
UsedArray.resize(List.size());
for (unsigned i = 0, e = List.size(); i != e; ++i) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
UsedArray[i] =
When generating llvm.used, we may need an addrspacecast instead of a bitcast. Summary: This is especially important for targets that use multiple address spaces, and commonly place global variables in address spaces other than zero. Fixes PR22383 Test Plan: New test case added: llvm-used.cu Reviewers: jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7345 llvm-svn: 227861
2015-02-03 05:05:49 +08:00
llvm::ConstantExpr::getPointerBitCastOrAddrSpaceCast(
cast<llvm::Constant>(&*List[i]), CGM.Int8PtrTy);
Change UsedArray to be a vector of WeakVH to fix a dangling pointer problem that occurs when attribute(used) and asm renaming are used together. llvm-svn: 68155
2009-04-01 06:37:52 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Patch fixes an obscure bug when 'used' attribute is applied to variables in ObjC's Next runtime mode. Next runtime also implicitly applies 'used' attribute on some of its meta-data. This results in two 'llvm.used' arrays to be generated, and one of them is renamed to 'llvm.used1'. llvm-svn: 74008
2009-06-24 05:47:46 +08:00
if (UsedArray.empty())
return;
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
llvm::ArrayType *ATy = llvm::ArrayType::get(CGM.Int8PtrTy, UsedArray.size());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = new llvm::GlobalVariable(
CGM.getModule(), ATy, false, llvm::GlobalValue::AppendingLinkage,
llvm::ConstantArray::get(ATy, UsedArray), Name);
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
GV->setSection("llvm.metadata");
}
Use llvm.compiler.used instead of llvm.used for objc symbols. LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the ones that the clang's objc codegen is producing. The net result, is that it is equivalent to llvm.compiler.used. The need for putting the private symbol in llvm.compiler.used should be clear (the objc runtime uses them). The reason for also putting the weak symbols in it is for LTO: ld64 will not ask us to preserve the it. llvm-svn: 203172
2014-03-07 06:15:10 +08:00
void CodeGenModule::emitLLVMUsed() {
emitUsed(*this, "llvm.used", LLVMUsed);
emitUsed(*this, "llvm.compiler.used", LLVMCompilerUsed);
}
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
void CodeGenModule::AppendLinkerOptions(StringRef Opts) {
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
auto *MDOpts = llvm::MDString::get(getLLVMContext(), Opts);
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
LinkerOptionsMetadata.push_back(llvm::MDNode::get(getLLVMContext(), MDOpts));
}
Adding support for MSVC #pragma detect_mismatch functionality by emitting a FAILIFMISMATCH linker command into the object file. llvm-svn: 183178
2013-06-04 10:07:14 +08:00
void CodeGenModule::AddDetectMismatch(StringRef Name, StringRef Value) {
llvm::SmallString<32> Opt;
getTargetCodeGenInfo().getDetectMismatchOption(Name, Value, Opt);
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
auto *MDOpts = llvm::MDString::get(getLLVMContext(), Opt);
Adding support for MSVC #pragma detect_mismatch functionality by emitting a FAILIFMISMATCH linker command into the object file. llvm-svn: 183178
2013-06-04 10:07:14 +08:00
LinkerOptionsMetadata.push_back(llvm::MDNode::get(getLLVMContext(), MDOpts));
}
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
void CodeGenModule::AddDependentLib(StringRef Lib) {
llvm::SmallString<24> Opt;
getTargetCodeGenInfo().getDependentLibraryOption(Lib, Opt);
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
auto *MDOpts = llvm::MDString::get(getLLVMContext(), Opt);
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
LinkerOptionsMetadata.push_back(llvm::MDNode::get(getLLVMContext(), MDOpts));
}
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
/// \brief Add link options implied by the given module, including modules
/// it depends on, using a postorder walk.
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
static void addLinkOptionsPostorder(CodeGenModule &CGM, Module *Mod,
IR: Replace the "Linker Options" module flag with "llvm.linker.options" named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
2017-06-13 04:10:48 +08:00
SmallVectorImpl<llvm::MDNode *> &Metadata,
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
llvm::SmallPtrSet<Module *, 16> &Visited) {
// Import this module's parent.
Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-11-19 15:49:47 +08:00
if (Mod->Parent && Visited.insert(Mod->Parent).second) {
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
addLinkOptionsPostorder(CGM, Mod->Parent, Metadata, Visited);
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
}
// Import this module's dependencies.
for (unsigned I = Mod->Imports.size(); I > 0; --I) {
Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-11-19 15:49:47 +08:00
if (Visited.insert(Mod->Imports[I - 1]).second)
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
addLinkOptionsPostorder(CGM, Mod->Imports[I-1], Metadata, Visited);
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
}
// Add linker options to link against the libraries/frameworks
// described by this module.
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
llvm::LLVMContext &Context = CGM.getLLVMContext();
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
for (unsigned I = Mod->LinkLibraries.size(); I > 0; --I) {
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
// Link against a framework. Frameworks are currently Darwin only, so we
// don't to ask TargetCodeGenInfo for the spelling of the linker option.
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
if (Mod->LinkLibraries[I-1].IsFramework) {
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::Metadata *Args[2] = {
llvm::MDString::get(Context, "-framework"),
llvm::MDString::get(Context, Mod->LinkLibraries[I - 1].Library)};
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
Metadata.push_back(llvm::MDNode::get(Context, Args));
continue;
}
// Link against a library.
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
llvm::SmallString<24> Opt;
CGM.getTargetCodeGenInfo().getDependentLibraryOption(
Mod->LinkLibraries[I-1].Library, Opt);
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
auto *OptString = llvm::MDString::get(Context, Opt);
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
Metadata.push_back(llvm::MDNode::get(Context, OptString));
}
}
void CodeGenModule::EmitModuleLinkOptions() {
// Collect the set of all of the modules we want to visit to emit link
// options, which is essentially the imported modules and all of their
// non-explicit child modules.
llvm::SetVector<clang::Module *> LinkModules;
llvm::SmallPtrSet<clang::Module *, 16> Visited;
SmallVector<clang::Module *, 16> Stack;
// Seed the stack with imported modules.
Module: Do not add any link flags when an implementation TU of a module imports a header of that same module. This fixes a regression caused by r280409. rdar://problem/29930553 This is an updated version for r291628 (which was reverted in r291688). llvm-svn: 291689
2017-01-12 02:47:38 +08:00
for (Module *M : ImportedModules) {
// Do not add any link flags when an implementation TU of a module imports
// a header of that same module.
if (M->getTopLevelModuleName() == getLangOpts().CurrentModule &&
!getLangOpts().isCompilingModule())
continue;
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
if (Visited.insert(M).second)
Stack.push_back(M);
Module: Do not add any link flags when an implementation TU of a module imports a header of that same module. This fixes a regression caused by r280409. rdar://problem/29930553 This is an updated version for r291628 (which was reverted in r291688). llvm-svn: 291689
2017-01-12 02:47:38 +08:00
}
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
// Find all of the modules to import, making a little effort to prune
// non-leaf modules.
while (!Stack.empty()) {
Use pop_back_val() instead of both back() and pop_back(). No functionality change intended. llvm-svn: 189112
2013-08-24 00:11:15 +08:00
clang::Module *Mod = Stack.pop_back_val();
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
bool AnyChildren = false;
// Visit the submodules of this module.
for (clang::Module::submodule_iterator Sub = Mod->submodule_begin(),
SubEnd = Mod->submodule_end();
Sub != SubEnd; ++Sub) {
// Skip explicit children; they need to be explicitly imported to be
// linked against.
if ((*Sub)->IsExplicit)
continue;
Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-11-19 15:49:47 +08:00
if (Visited.insert(*Sub).second) {
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
Stack.push_back(*Sub);
AnyChildren = true;
}
}
// We didn't find any children, so add this module to the list of
// modules to link against.
if (!AnyChildren) {
LinkModules.insert(Mod);
}
}
// Add link options for all of the imported modules in reverse topological
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
// order. We don't do anything to try to order import link flags with respect
// to linker options inserted by things like #pragma comment().
IR: Replace the "Linker Options" module flag with "llvm.linker.options" named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
2017-06-13 04:10:48 +08:00
SmallVector<llvm::MDNode *, 16> MetadataArgs;
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
Visited.clear();
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (Module *M : LinkModules)
if (Visited.insert(M).second)
addLinkOptionsPostorder(*this, M, MetadataArgs, Visited);
[IRgen] Update modules autolink metadata to use module flags (as now specified in the LangRef). llvm-svn: 172692
2013-01-17 09:35:06 +08:00
std::reverse(MetadataArgs.begin(), MetadataArgs.end());
Forward #pragma comment(lib/linker) through as flags metadata Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
2013-05-08 21:44:39 +08:00
LinkerOptionsMetadata.append(MetadataArgs.begin(), MetadataArgs.end());
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
[IRgen] Update modules autolink metadata to use module flags (as now specified in the LangRef). llvm-svn: 172692
2013-01-17 09:35:06 +08:00
// Add the linker options metadata flag.
IR: Replace the "Linker Options" module flag with "llvm.linker.options" named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
2017-06-13 04:10:48 +08:00
auto *NMD = getModule().getOrInsertNamedMetadata("llvm.linker.options");
for (auto *MD : LinkerOptionsMetadata)
NMD->addOperand(MD);
Topologically sort the link options generated for modules based on module-import dependencies, so we'll get the link order correct for those silly linkers that need it. llvm-svn: 172459
2013-01-15 04:53:57 +08:00
}
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
void CodeGenModule::EmitDeferred() {
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
// Emit code for any potentially referenced deferred decls. Since a
// previously unused static decl may become used during the generation of code
In C99, emit an inline function when encountering an extern redeclaration. Fixes PR10233! llvm-svn: 135377
2011-07-18 13:26:13 +08:00
// for a static function, iterate until no changes are made.
Delay codegen of vtables when handling implicit instantiations. This fixes PR6474. llvm-svn: 98123
2010-03-10 10:19:29 +08:00
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
if (!DeferredVTables.empty()) {
EmitDeferredVTables();
Use a consistent spelling for vtables. llvm-svn: 259137
2016-01-29 09:35:53 +08:00
// Emitting a vtable doesn't directly cause more vtables to
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// become deferred, although it can cause functions to be
Use a consistent spelling for vtables. llvm-svn: 259137
2016-01-29 09:35:53 +08:00
// emitted that then need those vtables.
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
assert(DeferredVTables.empty());
}
Delay codegen of vtables when handling implicit instantiations. This fixes PR6474. llvm-svn: 98123
2010-03-10 10:19:29 +08:00
Use a consistent spelling for vtables. llvm-svn: 259137
2016-01-29 09:35:53 +08:00
// Stop if we're out of both deferred vtables and deferred declarations.
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
if (DeferredDeclsToEmit.empty())
return;
The standard ARM C++ ABI dictates that inline functions are never key functions. We did not implement that rule for the iOS ABI, which was driven by what was implemented in gcc-4.2. However, implement it now for other ARM-based platforms. llvm-svn: 173515
2013-01-26 06:31:03 +08:00
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// Grab the list of decls to emit. If EmitGlobalDefinition schedules more
// work, it will not interfere with this.
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
std::vector<GlobalDecl> CurDeclsToEmit;
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
CurDeclsToEmit.swap(DeferredDeclsToEmit);
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
for (GlobalDecl &D : CurDeclsToEmit) {
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
// We should call GetAddrOfGlobal with IsForDefinition set to true in order
// to get GlobalValue with exactly the type we need, not something that
// might had been created for another decl with the same mangled name but
// different type.
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
llvm::GlobalValue *GV = dyn_cast<llvm::GlobalValue>(
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
GetAddrOfGlobal(D, ForDefinition));
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
// In case of different address spaces, we may still get a cast, even with
// IsForDefinition equal to true. Query mangled names table to get
// GlobalValue.
if (!GV)
GV = GetGlobalValue(getMangledName(D));
// Make sure GetGlobalValue returned non-null.
assert(GV);
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
When deciding whether a deferred declaration has already been emitted, aliases count as definitions regardless of whether their target has been emitted yet. Fixes PR 7142. llvm-svn: 104796
2010-05-27 09:45:30 +08:00
// Check to see if we've already emitted this. This is necessary
// for a couple of reasons: first, decls can end up in the
// deferred-decls queue multiple times, and second, decls can end
// up with definitions in unusual ways (e.g. by an extern inline
// function acquiring a strong function redefinition). Just
// ignore these cases.
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
if (!GV->isDeclaration())
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
continue;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
// Otherwise, emit the definition and move on to the next one.
Save another call to GetAddrOfFunction. Thread an optional GV down to EmitGlobalFunctionDefinition so that it can avoid the lookup when we already know the corresponding llvm global value. llvm-svn: 196789
2013-12-10 00:01:03 +08:00
EmitGlobalDefinition(D, GV);
Emit DeferredDeclsToEmit in a DFS order. Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that. The advantages of the change are that * The output order is a bit closer to the source order. The change to test/CodeGenCXX/pod-member-memcpys.cpp is a good example. * If we decide to deffer more, it will not cause as large changes in the estcases as it would without this patch. llvm-svn: 226751
2015-01-22 08:24:57 +08:00
// If we found out that we need to emit more decls, do that recursively.
// This has the advantage that the decls are emitted in a DFS and related
// ones are close together, which is convenient for testing.
if (!DeferredVTables.empty() || !DeferredDeclsToEmit.empty()) {
EmitDeferred();
assert(DeferredVTables.empty() && DeferredDeclsToEmit.empty());
}
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
}
Reorganize codegen files. llvm-svn: 39504
2007-05-28 09:07:47 +08:00
}
Build enough support for aggregates to be able to compile this: void test(int A, _Complex float Y) { _Complex float X; X = X; } llvm-svn: 39669
2007-06-23 02:48:09 +08:00
Emit available_externally vtables opportunistically Summary: We can emit vtable definition having inline function if they are all emitted. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33437 llvm-svn: 304394
2017-06-01 16:04:05 +08:00
void CodeGenModule::EmitVTablesOpportunistically() {
// Try to emit external vtables as available_externally if they have emitted
// all inlined virtual functions. It runs after EmitDeferred() and therefore
// is not allowed to create new references to things that need to be emitted
// lazily. Note that it also uses fact that we eagerly emitting RTTI.
Fixed warnings llvm-svn: 304397
2017-06-01 17:24:36 +08:00
assert((OpportunisticVTables.empty() || shouldOpportunisticallyEmitVTables())
&& "Only emit opportunistic vtables with optimizations");
Emit available_externally vtables opportunistically Summary: We can emit vtable definition having inline function if they are all emitted. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33437 llvm-svn: 304394
2017-06-01 16:04:05 +08:00
for (const CXXRecordDecl *RD : OpportunisticVTables) {
assert(getVTables().isVTableExternal(RD) &&
"This queue should only contain external vtables");
if (getCXXABI().canSpeculativelyEmitVTable(RD))
VTables.GenerateClassData(RD);
}
OpportunisticVTables.clear();
}
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
void CodeGenModule::EmitGlobalAnnotations() {
if (Annotations.empty())
return;
// Create a new global variable for the ConstantStruct in the Module.
llvm::Constant *Array = llvm::ConstantArray::get(llvm::ArrayType::get(
Annotations[0]->getType(), Annotations.size()), Annotations);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *gv = new llvm::GlobalVariable(getModule(), Array->getType(), false,
llvm::GlobalValue::AppendingLinkage,
Array, "llvm.global.annotations");
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
gv->setSection(AnnotationSection);
}
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
llvm::Constant *CodeGenModule::EmitAnnotationString(StringRef Str) {
Avoid double StringMap lookups. No functionality change. llvm-svn: 194355
2013-11-11 00:55:11 +08:00
llvm::Constant *&AStr = AnnotationStrings[Str];
if (AStr)
return AStr;
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
// Not found yet, create a new global.
reapply the patches reverted in r149477, which enable ConstantDataArray. llvm-svn: 149801
2012-02-05 10:30:40 +08:00
llvm::Constant *s = llvm::ConstantDataArray::getString(getLLVMContext(), Str);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *gv =
new llvm::GlobalVariable(getModule(), s->getType(), true,
llvm::GlobalValue::PrivateLinkage, s, ".str");
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
gv->setSection(AnnotationSection);
Update clang for D20348 Differential Revision: http://reviews.llvm.org/D20339 llvm-svn: 272710
2016-06-15 05:02:05 +08:00
gv->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
Avoid double StringMap lookups. No functionality change. llvm-svn: 194355
2013-11-11 00:55:11 +08:00
AStr = gv;
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
return gv;
}
llvm::Constant *CodeGenModule::EmitAnnotationUnit(SourceLocation Loc) {
SourceManager &SM = getContext().getSourceManager();
PresumedLoc PLoc = SM.getPresumedLoc(Loc);
if (PLoc.isValid())
return EmitAnnotationString(PLoc.getFilename());
return EmitAnnotationString(SM.getBufferName(Loc));
}
llvm::Constant *CodeGenModule::EmitAnnotationLineNo(SourceLocation L) {
SourceManager &SM = getContext().getSourceManager();
PresumedLoc PLoc = SM.getPresumedLoc(L);
unsigned LineNo = PLoc.isValid() ? PLoc.getLine() :
SM.getExpansionLineNumber(L);
return llvm::ConstantInt::get(Int32Ty, LineNo);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
llvm::Constant *CodeGenModule::EmitAnnotateAttr(llvm::GlobalValue *GV,
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
const AnnotateAttr *AA,
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
SourceLocation L) {
// Get the globals for file name, annotation, and the line number.
llvm::Constant *AnnoGV = EmitAnnotationString(AA->getAnnotation()),
*UnitGV = EmitAnnotationUnit(L),
*LineNoCst = EmitAnnotationLineNo(L);
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
Comment fix. llvm-svn: 69091
2009-04-15 06:41:13 +08:00
// Create the ConstantStruct for the global annotation.
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
llvm::Constant *Fields[4] = {
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
llvm::ConstantExpr::getBitCast(GV, Int8PtrTy),
llvm::ConstantExpr::getBitCast(AnnoGV, Int8PtrTy),
llvm::ConstantExpr::getBitCast(UnitGV, Int8PtrTy),
LineNoCst
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
};
Update to match mainline ConstantStruct::get API change. Also, use ConvertType on InitListExprs as they are being converted. This is needed for a forthcoming patch, and improves the IR generated anyway (see additional type names in testcases). This patch also converts a bunch of std::vector's in CGObjCMac to use C arrays. There are a ton more that should be converted as well. llvm-svn: 133413
2011-06-20 12:01:35 +08:00
return llvm::ConstantStruct::getAnon(Fields);
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
}
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
void CodeGenModule::AddGlobalAnnotations(const ValueDecl *D,
llvm::GlobalValue *GV) {
assert(D->hasAttr<AnnotateAttr>() && "no annotate attribute");
// Get the struct elements for these annotations.
[C++11] Replacing DeclBase iterators specific_attr_begin() and specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203474
2014-03-11 01:08:28 +08:00
for (const auto *I : D->specific_attrs<AnnotateAttr>())
Annotations.push_back(EmitAnnotateAttr(GV, I, D->getLocation()));
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
}
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
bool CodeGenModule::isInSanitizerBlacklist(SanitizerMask Kind,
llvm::Function *Fn,
SanitizerBlacklist: blacklist functions by their source location. This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
2014-10-17 08:20:19 +08:00
SourceLocation Loc) const {
const auto &SanitizerBL = getContext().getSanitizerBlacklist();
// Blacklist by function name.
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
if (SanitizerBL.isBlacklistedFunction(Kind, Fn->getName()))
SanitizerBlacklist: blacklist functions by their source location. This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
2014-10-17 08:20:19 +08:00
return true;
// Blacklist by location.
Replace double-negated !SourceLocation.isInvalid() with SourceLocation.isValid(). llvm-svn: 249228
2015-10-03 13:15:57 +08:00
if (Loc.isValid())
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
return SanitizerBL.isBlacklistedLocation(Kind, Loc);
SanitizerBlacklist: blacklist functions by their source location. This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
2014-10-17 08:20:19 +08:00
// If location is unknown, this may be a compiler-generated function. Assume
// it's located in the main file.
auto &SM = Context.getSourceManager();
if (const auto *MainFile = SM.getFileEntryForID(SM.getMainFileID())) {
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
return SanitizerBL.isBlacklistedFile(Kind, MainFile->getName());
SanitizerBlacklist: blacklist functions by their source location. This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
2014-10-17 08:20:19 +08:00
}
return false;
}
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
bool CodeGenModule::isInSanitizerBlacklist(llvm::GlobalVariable *GV,
SourceLocation Loc, QualType Ty,
StringRef Category) const {
[ASan] Initial support for Kernel AddressSanitizer This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
2015-06-19 20:19:07 +08:00
// For now globals can be blacklisted only in ASan and KASan.
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
const SanitizerMask EnabledAsanMask = LangOpts.Sanitize.Mask &
Hardware-assisted AddressSanitizer (clang part). Summary: Driver, frontend and LLVM codegen for HWASan. A clone of ASan, basically. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D40936 llvm-svn: 320232
2017-12-09 09:32:07 +08:00
(SanitizerKind::Address | SanitizerKind::KernelAddress | SanitizerKind::HWAddress);
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
if (!EnabledAsanMask)
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
return false;
const auto &SanitizerBL = getContext().getSanitizerBlacklist();
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
if (SanitizerBL.isBlacklistedGlobal(EnabledAsanMask, GV->getName(), Category))
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
return true;
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
if (SanitizerBL.isBlacklistedLocation(EnabledAsanMask, Loc, Category))
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
return true;
// Check global type.
if (!Ty.isNull()) {
// Drill down the array types: if global variable of a fixed type is
// blacklisted, we also don't instrument arrays of them.
while (auto AT = dyn_cast<ArrayType>(Ty.getTypePtr()))
Ty = AT->getElementType();
Ty = Ty.getCanonicalType().getUnqualifiedType();
// We allow to blacklist only record types (classes, structs etc.)
if (Ty->isRecordType()) {
std::string TypeStr = Ty.getAsString(getContext().getPrintingPolicy());
Allow specifying sanitizers in blacklists Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
2017-09-26 06:11:12 +08:00
if (SanitizerBL.isBlacklistedType(EnabledAsanMask, TypeStr, Category))
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
return true;
}
}
return false;
}
[XRay] Add -fxray-{always,never}-instrument= flags to clang Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
2017-03-30 08:29:36 +08:00
bool CodeGenModule::imbueXRayAttrs(llvm::Function *Fn, SourceLocation Loc,
StringRef Category) const {
if (!LangOpts.XRayInstrument)
return false;
const auto &XRayFilter = getContext().getXRayFilter();
using ImbueAttr = XRayFunctionFilter::ImbueAttribute;
auto Attr = XRayFunctionFilter::ImbueAttribute::NONE;
if (Loc.isValid())
Attr = XRayFilter.shouldImbueLocation(Loc, Category);
if (Attr == ImbueAttr::NONE)
Attr = XRayFilter.shouldImbueFunction(Fn->getName());
switch (Attr) {
case ImbueAttr::NONE:
return false;
case ImbueAttr::ALWAYS:
Fn->addFnAttr("function-instrument", "xray-always");
break;
[XRay][clang] Allow imbuing arg1 logging attribute via -fxray-always-instrument= Summary: This change allows us to add arg1 logging support to functions through the special case list provided through -fxray-always-instrument=. This is useful for adding arg1 logging to functions that are either in headers that users don't have control over (i.e. cannot change the source) or would rather not do. It only takes effect when the pattern is matched through the "fun:" special case, as a category. As in: fun:*pattern=arg1 Reviewers: pelikan, rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33392 llvm-svn: 303719
2017-05-24 13:46:36 +08:00
case ImbueAttr::ALWAYS_ARG1:
Fn->addFnAttr("function-instrument", "xray-always");
Fn->addFnAttr("xray-log-args", "1");
break;
[XRay] Add -fxray-{always,never}-instrument= flags to clang Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
2017-03-30 08:29:36 +08:00
case ImbueAttr::NEVER:
Fn->addFnAttr("function-instrument", "xray-never");
break;
}
return true;
}
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
bool CodeGenModule::MustBeEmitted(const ValueDecl *Global) {
Merge PCHWriterDecl.cpp's isRequiredDecl and CodeGenModule::MayDeferGeneration into a new function, DeclIsRequiredFunctionOrFileScopedVar. This is essentially a CodeGen predicate that is also needed by the PCH mechanism to determine whether a decl needs to be deserialized during PCH loading for codegen purposes. Since this logic is shared by CodeGen and the PCH mechanism, move it to the ASTContext, thus CodeGenModule's GetLinkageForFunction/GetLinkageForVariable and the GVALinkage enum is moved out of CodeGen. This fixes current (and avoids future) codegen-from-PCH bugs. llvm-svn: 109784
2010-07-30 02:15:58 +08:00
// Never defer when EmitAllDecls is specified.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.EmitAllDecls)
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
return true;
return getContext().DeclMustBeEmitted(Global);
}
When a function or variable somehow depends on a type or declaration that is in an anonymous namespace, give that function or variable internal linkage. This change models an oddity of the C++ standard, where names declared in an anonymous namespace have external linkage but, because anonymous namespace are really "uniquely-named" namespaces, the names cannot be referenced from other translation units. That means that they have external linkage for semantic analysis, but the only sensible implementation for code generation is to give them internal linkage. We now model this notion via the UniqueExternalLinkage linkage type. There are several changes here: - Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage when the declaration is in an anonymous namespace. - Added Type::getLinkage() to determine the linkage of a type, which is defined as the minimum linkage of the types (when we're dealing with a compound type that is not a struct/class/union). - Extended NamedDecl::getLinkage() to consider the linkage of the template arguments and template parameters of function template specializations and class template specializations. - Taught code generation to rely on NamedDecl::getLinkage() when determining the linkage of variables and functions, also considering the linkage of the types of those variables and functions (C++ only). Map UniqueExternalLinkage to internal linkage, taking out the explicit checks for isInAnonymousNamespace(). This fixes much of PR5792, which, as discovered by Anders Carlsson, is actually the reason behind the pass-manager assertion that causes the majority of clang-on-clang regression test failures. With this fix, Clang-built-Clang+LLVM passes 88% of its regression tests (up from 67%). The specific numbers are: LLVM: Expected Passes : 4006 Expected Failures : 32 Unsupported Tests : 40 Unexpected Failures: 736 Clang: Expected Passes : 1903 Expected Failures : 14 Unexpected Failures: 75 Overall: Expected Passes : 5909 Expected Failures : 46 Unsupported Tests : 40 Unexpected Failures: 811 Still to do: - Improve testing - Check whether we should allow the presence of types with InternalLinkage (in addition to UniqueExternalLinkage) given variables/functions internal linkage in C++, as mentioned in PR5792. - Determine how expensive the getLinkage() calls are in practice; consider caching the result in NamedDecl. - Assess the feasibility of Chris's idea in comment #1 of PR5792. llvm-svn: 95216
2010-02-03 17:33:45 +08:00
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
bool CodeGenModule::MayBeEmittedEagerly(const ValueDecl *Global) {
if (const auto *FD = dyn_cast<FunctionDecl>(Global))
if (FD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation)
// Implicit template instantiations may change linkage if they are later
// explicitly instantiated, so they should not be emitted eagerly.
return false;
PR28394: For compatibility with c++11 and c++14, if a static constexpr data member is redundantly redeclared outside the class definition in code built in c++17 mode, ensure we emit a non-discardable definition of the data member for c++11 and c++14 compilations to use. llvm-svn: 274416
2016-07-02 09:32:16 +08:00
if (const auto *VD = dyn_cast<VarDecl>(Global))
if (Context.getInlineVariableDefinitionKind(VD) ==
ASTContext::InlineVariableDefinitionKind::WeakUnknown)
// A definition of an inline constexpr static data member may change
// linkage later if it's redeclared outside the class.
return false;
[OpenMP] Add TLS-based implementation for threadprivate directive. llvm-svn: 242080
2015-07-14 06:54:53 +08:00
// If OpenMP is enabled and threadprivates must be generated like TLS, delay
// codegen for global variables, because they may be marked as threadprivate.
if (LangOpts.OpenMP && LangOpts.OpenMPUseTLS &&
getContext().getTargetInfo().isTLSSupported() && isa<VarDecl>(Global))
return false;
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
return true;
Pull MayDeferGeneration out of EmitGlobal. - Fix emission of static functions with constructor attribute while I was here. <rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly llvm-svn: 64488
2009-02-14 05:18:01 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress CodeGenModule::GetAddrOfUuidDescriptor(
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
const CXXUuidofExpr* E) {
// Sema has verified that IIDSource has a __declspec(uuid()), and that its
// well-formed.
Fix serialization/deserialization for __uuidof I broke this back in r264529 because I forgot to serialize the UuidAttr member. Fix this by replacing the UuidAttr with a StringRef which is properly serialized and deserialized. llvm-svn: 264562
2016-03-28 11:19:50 +08:00
StringRef Uuid = E->getUuidStr();
[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section Revert r188055 which reverted r188053. An unrelated change previously snuck in. llvm-svn: 188060
2013-08-09 16:35:59 +08:00
std::string Name = "_GUID_" + Uuid.lower();
std::replace(Name.begin(), Name.end(), '-', '_');
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
Use the correct alignment for uuid descriptors The _GUID_ descriptors emitted by MSVC have alignment 8 for 64-bit builds: we should do the same if the linker picks the "wrong" COMDAT. llvm-svn: 264530
2016-03-27 12:46:14 +08:00
// The UUID descriptor should be pointer aligned.
CharUnits Alignment = CharUnits::fromQuantity(PointerAlignInBytes);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
// Look for an existing global.
if (llvm::GlobalVariable *GV = getModule().getNamedGlobal(Name))
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(GV, Alignment);
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
Remove a parameter that has been unused since r188481. No behavior change. llvm-svn: 217386
2014-09-09 00:26:36 +08:00
llvm::Constant *Init = EmitUuidofInitializer(Uuid);
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
assert(Init && "failed to initialize as constant");
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = new llvm::GlobalVariable(
CodeGen: __uuidof should work even with an incomplete _GUID type Summary: We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue will be foiled: the type of the constant value is incomplete. Instead, create an unnamed type with the proper layout on all platforms. Punt the problem of wrongly defined struct _GUID types to the user. (It's impossible because the TU may never get to see the type and thus we can't verify that it is suitable.) This fixes PR16856. Reviewers: rsmith, rnk, thakis Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1375 llvm-svn: 188481
2013-08-16 03:59:14 +08:00
getModule(), Init->getType(),
Emit uuid globals as linkonce_odr Patch by Nico Rieck! llvm-svn: 189860
2013-09-04 05:49:32 +08:00
/*isConstant=*/true, llvm::GlobalValue::LinkOnceODRLinkage, Init, Name);
Revert r236879, "Do not emit thunks with available_externally linkage in comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
2015-05-10 05:10:07 +08:00
if (supportsCOMDAT())
GV->setComdat(TheModule.getOrInsertComdat(GV->getName()));
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(GV, Alignment);
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress CodeGenModule::GetWeakRefReference(const ValueDecl *VD) {
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
const AliasAttr *AA = VD->getAttr<AliasAttr>();
assert(AA && "No alias?");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment = getContext().getDeclAlign(VD);
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *DeclTy = getTypes().ConvertTypeForMem(VD->getType());
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
// See if there is already something with the target's name in the module.
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
llvm::GlobalValue *Entry = GetGlobalValue(AA->getAliasee());
When using a symbol with attribute weakref, search for it first and don't try the normal GetOrCreateLLVM. The latter could drop the weak atrtibute on the second reference, if there is no explicit declaration of the aliasee. llvm-svn: 166032
2012-10-17 01:45:27 +08:00
if (Entry) {
unsigned AS = getContext().getTargetAddressSpace(VD->getType());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
auto Ptr = llvm::ConstantExpr::getBitCast(Entry, DeclTy->getPointerTo(AS));
return ConstantAddress(Ptr, Alignment);
When using a symbol with attribute weakref, search for it first and don't try the normal GetOrCreateLLVM. The latter could drop the weak atrtibute on the second reference, if there is no explicit declaration of the aliasee. llvm-svn: 166032
2012-10-17 01:45:27 +08:00
}
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
llvm::Constant *Aliasee;
if (isa<llvm::FunctionType>(DeclTy))
Propagate calling convention for aliases and weakrefs. llvm-svn: 165343
2012-10-06 07:12:53 +08:00
Aliasee = GetOrCreateLLVMFunction(AA->getAliasee(), DeclTy,
GlobalDecl(cast<FunctionDecl>(VD)),
Re-land r124768, with a fix for PR9130. We now emit everything except unused implicit virtual member functions when building the vtable. llvm-svn: 124935
2011-02-05 12:35:53 +08:00
/*ForVTable=*/false);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
else
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(),
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::PointerType::getUnqual(DeclTy),
nullptr);
When using a symbol with attribute weakref, search for it first and don't try the normal GetOrCreateLLVM. The latter could drop the weak atrtibute on the second reference, if there is no explicit declaration of the aliasee. llvm-svn: 166032
2012-10-17 01:45:27 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *F = cast<llvm::GlobalValue>(Aliasee);
When using a symbol with attribute weakref, search for it first and don't try the normal GetOrCreateLLVM. The latter could drop the weak atrtibute on the second reference, if there is no explicit declaration of the aliasee. llvm-svn: 166032
2012-10-17 01:45:27 +08:00
F->setLinkage(llvm::Function::ExternalWeakLinkage);
WeakRefReferences.insert(F);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(Aliasee, Alignment);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
}
push GlobalDecl through enough of the CodeGenModule interfaces to allow us to support generation of deferred ctors/dtors. It looks like codegen isn't emitting a call to the dtor in member-functions.cpp:test2, but when it does, its body should get emitted. llvm-svn: 71594
2009-05-13 05:21:08 +08:00
void CodeGenModule::EmitGlobal(GlobalDecl GD) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *Global = cast<ValueDecl>(GD.getDecl());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
// Weak references don't produce any output by themselves.
if (Global->hasAttr<WeakRefAttr>())
return;
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
// If this is an alias definition (which otherwise looks like a declaration)
// emit it now.
Remove the ASTContext parameter from the attribute-related methods of Decl. The implementations of these methods can Use Decl::getASTContext() to get the ASTContext. This commit touches a lot of files since call sites for these methods are everywhere. I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it. llvm-svn: 74501
2009-06-30 10:34:44 +08:00
if (Global->hasAttr<AliasAttr>())
Revert "This patch causes clang to reject alias attributes that point to undefined names. For example, with this patch we now reject" This reverts commit r193161. It broke void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); Looks like we have to fix pr17639 first :-( llvm-svn: 193162
2013-10-22 22:23:09 +08:00
return EmitAliasDefinition(GD);
Fix a number of issues w.r.t. emission of global for functions and aliases. - Attributes specific to a definition are only set when the definition is seen. - Alias generation is delayed until the end of the module; necessary since the alias may reference forward. - Fixes: PR2743, <rdr://6140807&6094512> - Improves: <rdr://6095112> (added XFAIL) Also, print module on verification failures. llvm-svn: 55966
2008-09-09 07:44:31 +08:00
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
// IFunc like an alias whose value is resolved at runtime by calling resolver.
if (Global->hasAttr<IFuncAttr>())
return emitIFuncDefinition(GD);
CUDA: add -fcuda-is-device flag This frontend-only flag is used by the IR generator to determine whether to filter CUDA declarations for the host or for the device. llvm-svn: 141301
2011-10-07 02:29:46 +08:00
// If this is CUDA, be selective about which declarations we emit.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (LangOpts.CUDA) {
Remove .CUDAIsDevice flags from CodeGenOpts as it's already available in LangOpts. Differential Revision: http://reviews.llvm.org/D8385 llvm-svn: 232749
2015-03-20 02:58:18 +08:00
if (LangOpts.CUDAIsDevice) {
CUDA: add -fcuda-is-device flag This frontend-only flag is used by the IR generator to determine whether to filter CUDA declarations for the host or for the device. llvm-svn: 141301
2011-10-07 02:29:46 +08:00
if (!Global->hasAttr<CUDADeviceAttr>() &&
!Global->hasAttr<CUDAGlobalAttr>() &&
!Global->hasAttr<CUDAConstantAttr>() &&
!Global->hasAttr<CUDASharedAttr>())
return;
} else {
[CUDA] Emit host-side 'shadows' for device-side global variables ... and register them with CUDA runtime. This is needed for commonly used cudaMemcpy*() APIs that use address of host-side shadow to access their counterparts on device side. Fixes PR26340 Differential Revision: http://reviews.llvm.org/D17779 llvm-svn: 262498
2016-03-03 02:28:50 +08:00
// We need to emit host-side 'shadows' for all global
// device-side variables because the CUDA runtime needs their
// size and host-side address in order to provide access to
// their device-side incarnations.
// So device-only functions are the only things we skip.
if (isa<FunctionDecl>(Global) && !Global->hasAttr<CUDAHostAttr>() &&
Global->hasAttr<CUDADeviceAttr>())
CUDA: add -fcuda-is-device flag This frontend-only flag is used by the IR generator to determine whether to filter CUDA declarations for the host or for the device. llvm-svn: 141301
2011-10-07 02:29:46 +08:00
return;
[CUDA] Emit host-side 'shadows' for device-side global variables ... and register them with CUDA runtime. This is needed for commonly used cudaMemcpy*() APIs that use address of host-side shadow to access their counterparts on device side. Fixes PR26340 Differential Revision: http://reviews.llvm.org/D17779 llvm-svn: 262498
2016-03-03 02:28:50 +08:00
assert((isa<FunctionDecl>(Global) || isa<VarDecl>(Global)) &&
"Expected Variable or Function");
CUDA: add -fcuda-is-device flag This frontend-only flag is used by the IR generator to determine whether to filter CUDA declarations for the host or for the device. llvm-svn: 141301
2011-10-07 02:29:46 +08:00
}
}
[OPENMP 4.0] Codegen for 'declare reduction' construct. Emit function for 'combiner' part of 'declare reduction' construct and 'initialilzer' part, if any. llvm-svn: 262699
2016-03-04 17:22:22 +08:00
if (LangOpts.OpenMP) {
// If this is OpenMP device, check if it is legal to emit this global
// normally.
if (OpenMPRuntime && OpenMPRuntime->emitTargetGlobal(GD))
return;
if (auto *DRD = dyn_cast<OMPDeclareReductionDecl>(Global)) {
if (MustBeEmitted(Global))
EmitOMPDeclareReduction(DRD);
return;
}
}
[OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and device codegen. This patch attempts to fix the regressions identified when the patch was committed initially. Thanks to Michael Liao for identifying the fix in the offloading metadata generation related with side effects in evaluation of function arguments. llvm-svn: 256933
2016-01-06 21:42:12 +08:00
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
// Ignore declarations, they will be emitted on their first use.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *FD = dyn_cast<FunctionDecl>(Global)) {
Pull MayDeferGeneration out of EmitGlobal. - Fix emission of static functions with constructor attribute while I was here. <rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly llvm-svn: 64488
2009-02-14 05:18:01 +08:00
// Forward declarations are emitted lazily on first use.
In C99, emit an inline function when encountering an extern redeclaration. Fixes PR10233! llvm-svn: 135377
2011-07-18 13:26:13 +08:00
if (!FD->doesThisDeclarationHaveABody()) {
if (!FD->doesDeclarationForceExternallyVisibleDefinition())
return;
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef MangledName = getMangledName(GD);
CodeGen: Don't crash when replacing functions The peculiarities of C99 create scenario where an LLVM IR function declaration may need to be replaced with a definition baring a different type because the prototype and definition are not required to agree. However, we were not properly deferring this when it occurred. This fixes PR19280. llvm-svn: 205099
2014-03-29 22:19:55 +08:00
// Compute the function info and LLVM type.
const CGFunctionInfo &FI = getTypes().arrangeGlobalDeclaration(GD);
llvm::Type *Ty = getTypes().GetFunctionType(FI);
GetOrCreateLLVMFunction(MangledName, Ty, GD, /*ForVTable=*/false,
/*DontDefer=*/false);
Pull MayDeferGeneration out of EmitGlobal. - Fix emission of static functions with constructor attribute while I was here. <rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly llvm-svn: 64488
2009-02-14 05:18:01 +08:00
return;
In C99, emit an inline function when encountering an extern redeclaration. Fixes PR10233! llvm-svn: 135377
2011-07-18 13:26:13 +08:00
}
Rename EmitStatics (etc) to EmitDeferred; provide basic infrastructure for attribute used support. - No functionality change. llvm-svn: 64487
2009-02-14 04:29:50 +08:00
} else {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *VD = cast<VarDecl>(Global);
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
assert(VD->isFileVarDecl() && "Cannot emit local var decl as global.");
[CUDA] Emit host-side 'shadows' for device-side global variables ... and register them with CUDA runtime. This is needed for commonly used cudaMemcpy*() APIs that use address of host-side shadow to access their counterparts on device side. Fixes PR26340 Differential Revision: http://reviews.llvm.org/D17779 llvm-svn: 262498
2016-03-03 02:28:50 +08:00
// We need to emit device-side global CUDA variables even if a
// variable does not have a definition -- we still need to define
// host-side shadow for it.
bool MustEmitForCuda = LangOpts.CUDA && !LangOpts.CUDAIsDevice &&
!VD->hasDefinition() &&
(VD->hasAttr<CUDAConstantAttr>() ||
VD->hasAttr<CUDADeviceAttr>());
if (!MustEmitForCuda &&
VD->isThisDeclarationADefinition() != VarDecl::Definition &&
PR28394: For compatibility with c++11 and c++14, if a static constexpr data member is redundantly redeclared outside the class definition in code built in c++17 mode, ensure we emit a non-discardable definition of the data member for c++11 and c++14 compilations to use. llvm-svn: 274416
2016-07-02 09:32:16 +08:00
!Context.isMSStaticDataMemberInlineDefinition(VD)) {
// If this declaration may have caused an inline variable definition to
// change linkage, make sure that it's emitted.
if (Context.getInlineVariableDefinitionKind(VD) ==
ASTContext::InlineVariableDefinitionKind::Strong)
GetAddrOfGlobalVar(VD);
Pull MayDeferGeneration out of EmitGlobal. - Fix emission of static functions with constructor attribute while I was here. <rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly llvm-svn: 64488
2009-02-14 05:18:01 +08:00
return;
PR28394: For compatibility with c++11 and c++14, if a static constexpr data member is redundantly redeclared outside the class definition in code built in c++17 mode, ensure we emit a non-discardable definition of the data member for c++11 and c++14 compilations to use. llvm-svn: 274416
2016-07-02 09:32:16 +08:00
}
Only generate code for static functions and global variables that are actually used. Warn about unused static functions and variables. This fixes PR1998. llvm-svn: 49987
2008-04-20 14:29:50 +08:00
}
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
// Defer code generation to first use when possible, e.g. if this is an inline
// function. If the global must always be emitted, do it eagerly if possible
// to benefit from cache locality.
if (MustBeEmitted(Global) && MayBeEmittedEagerly(Global)) {
minor cleanups llvm-svn: 101151
2010-04-14 01:39:09 +08:00
// Emit the definition if it can't be deferred.
EmitGlobalDefinition(GD);
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
return;
}
When deferring the emission of declarations with initializers in C++, remember the order they appeared in the translation unit. If they get emitted, put them in their proper order. Fixes rdar://problem/7458115 llvm-svn: 108477
2010-07-16 07:40:35 +08:00
// If we're deferring emission of a C++ variable with an
// initializer, remember the order in which it appeared in the file.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().CPlusPlus && isa<VarDecl>(Global) &&
When deferring the emission of declarations with initializers in C++, remember the order they appeared in the translation unit. If they get emitted, put them in their proper order. Fixes rdar://problem/7458115 llvm-svn: 108477
2010-07-16 07:40:35 +08:00
cast<VarDecl>(Global)->hasInit()) {
DelayedCXXInitPosition[Global] = CXXGlobalInits.size();
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
CXXGlobalInits.push_back(nullptr);
When deferring the emission of declarations with initializers in C++, remember the order they appeared in the translation unit. If they get emitted, put them in their proper order. Fixes rdar://problem/7458115 llvm-svn: 108477
2010-07-16 07:40:35 +08:00
}
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef MangledName = getMangledName(GD);
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
if (GetGlobalValue(MangledName) != nullptr) {
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
// The value has already been used and should therefore be emitted.
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(GD);
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
} else if (MustBeEmitted(Global)) {
// The value must be emitted, but cannot be emitted eagerly.
assert(!MayBeEmittedEagerly(Global));
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(GD);
Don't emit implicit template instantiations eagerly (PR21718) Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
2015-01-10 09:19:48 +08:00
} else {
minor cleanups llvm-svn: 101151
2010-04-14 01:39:09 +08:00
// Otherwise, remember that we saw a deferred decl with this name. The
// first use of the mangled name will cause it to move into
// DeferredDeclsToEmit.
DeferredDecls[MangledName] = GD;
}
Only generate code for static functions and global variables that are actually used. Warn about unused static functions and variables. This fixes PR1998. llvm-svn: 49987
2008-04-20 14:29:50 +08:00
}
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
// Check if T is a class type with a destructor that's not dllimport.
static bool HasNonDllImportDtor(QualType T) {
if (const auto *RT = T->getBaseElementTypeUnsafe()->getAs<RecordType>())
if (CXXRecordDecl *RD = dyn_cast<CXXRecordDecl>(RT->getDecl()))
if (RD->getDestructor() && !RD->getDestructor()->hasAttr<DLLImportAttr>())
return true;
return false;
}
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
namespace {
struct FunctionIsDirectlyRecursive :
public RecursiveASTVisitor<FunctionIsDirectlyRecursive> {
const StringRef Name;
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
const Builtin::Context &BI;
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
bool Result;
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
FunctionIsDirectlyRecursive(StringRef N, const Builtin::Context &C) :
Name(N), BI(C), Result(false) {
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
}
typedef RecursiveASTVisitor<FunctionIsDirectlyRecursive> Base;
bool TraverseCallExpr(CallExpr *E) {
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
const FunctionDecl *FD = E->getDirectCallee();
if (!FD)
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
return true;
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
AsmLabelAttr *Attr = FD->getAttr<AsmLabelAttr>();
if (Attr && Name == Attr->getLabel()) {
Result = true;
return false;
}
unsigned BuiltinID = FD->getBuiltinID();
[CodeGen] Restrict isTriviallyRecursive to predefined lib functions forwarding to lib functions isTriviallyRecursive is only supposed to guard functions part of the implementation. This fixes PR23953. llvm-svn: 240735
2015-06-26 07:50:40 +08:00
if (!BuiltinID || !BI.isLibFunction(BuiltinID))
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
return true;
Rename the non-coding style conformant functions in namespace Builtins to match the rest of their brethren and reformat the bits that need it. llvm-svn: 244186
2015-08-06 09:01:12 +08:00
StringRef BuiltinName = BI.getName(BuiltinID);
Fix a string over-run detected by ASAN. llvm-svn: 148375
2012-01-18 11:41:19 +08:00
if (BuiltinName.startswith("__builtin_") &&
Name == BuiltinName.slice(strlen("__builtin_"), StringRef::npos)) {
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
Result = true;
return false;
}
return true;
}
};
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
// Make sure we're not referencing non-imported vars or functions.
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
struct DLLImportFunctionVisitor
: public RecursiveASTVisitor<DLLImportFunctionVisitor> {
bool SafeToInline = true;
Also don't inline dllimport functions referring to non-dllimport constructors. The AST walker wasn't visiting CXXConstructExprs before. This is a follow-up to r281395. llvm-svn: 281413
2016-09-14 06:51:42 +08:00
bool shouldVisitImplicitCode() const { return true; }
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
bool VisitVarDecl(VarDecl *VD) {
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
if (VD->getTLSKind()) {
// A thread-local variable cannot be imported.
SafeToInline = false;
return SafeToInline;
}
// A variable definition might imply a destructor call.
if (VD->isThisDeclarationADefinition())
SafeToInline = !HasNonDllImportDtor(VD->getType());
return SafeToInline;
}
bool VisitCXXBindTemporaryExpr(CXXBindTemporaryExpr *E) {
if (const auto *D = E->getTemporary()->getDestructor())
SafeToInline = D->hasAttr<DLLImportAttr>();
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
return SafeToInline;
}
bool VisitDeclRefExpr(DeclRefExpr *E) {
ValueDecl *VD = E->getDecl();
if (isa<FunctionDecl>(VD))
SafeToInline = VD->hasAttr<DLLImportAttr>();
else if (VarDecl *V = dyn_cast<VarDecl>(VD))
SafeToInline = !V->hasGlobalStorage() || V->hasAttr<DLLImportAttr>();
return SafeToInline;
}
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
Also don't inline dllimport functions referring to non-dllimport constructors. The AST walker wasn't visiting CXXConstructExprs before. This is a follow-up to r281395. llvm-svn: 281413
2016-09-14 06:51:42 +08:00
bool VisitCXXConstructExpr(CXXConstructExpr *E) {
SafeToInline = E->getConstructor()->hasAttr<DLLImportAttr>();
return SafeToInline;
}
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
Re-commit "Don't inline dllimport functions referencing non-imported methods" This re-commits r292522 with the addition that it also handles calls through pointer to member functions without crashing. llvm-svn: 292856
2017-01-24 07:57:50 +08:00
bool VisitCXXMemberCallExpr(CXXMemberCallExpr *E) {
CXXMethodDecl *M = E->getMethodDecl();
if (!M) {
// Call through a pointer to member function. This is safe to inline.
SafeToInline = true;
} else {
SafeToInline = M->hasAttr<DLLImportAttr>();
}
return SafeToInline;
}
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
bool VisitCXXDeleteExpr(CXXDeleteExpr *E) {
SafeToInline = E->getOperatorDelete()->hasAttr<DLLImportAttr>();
return SafeToInline;
}
[dllimport] Check for dtor references in functions Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
2017-02-16 07:28:10 +08:00
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
bool VisitCXXNewExpr(CXXNewExpr *E) {
SafeToInline = E->getOperatorNew()->hasAttr<DLLImportAttr>();
return SafeToInline;
}
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
// isTriviallyRecursive - Check if this function calls another
// decl that, because of the asm attribute or the other decl being a builtin,
// ends up pointing to itself.
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
bool
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
CodeGenModule::isTriviallyRecursive(const FunctionDecl *FD) {
StringRef Name;
if (getCXXABI().getMangleContext().shouldMangleDeclName(FD)) {
Fix special king of typo. llvm-svn: 148368
2012-01-18 09:50:13 +08:00
// asm labels are a special kind of mangling we have to support.
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
AsmLabelAttr *Attr = FD->getAttr<AsmLabelAttr>();
if (!Attr)
return false;
Name = Attr->getLabel();
} else {
Name = FD->getName();
}
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
[CodeGen] Tweak isTriviallyRecursive further isTriviallyRecursive is a hack used to bridge a gap between the expectations that source code assumes and the semantics that LLVM IR can provide. Specifically, asm labels on functions are treated as an explicit name for a GlobalObject in Clang but treated like an output-processing step in GCC. Tweak this hack a little further to emit calls to library functions instead of emitting an incorrect definition. The definition in question would have available_externally linkage (this is OK) but result in a call to itself which will either result in an infinite loop or stack overflow. This fixes PR23964. llvm-svn: 241043
2015-06-30 12:41:18 +08:00
FunctionIsDirectlyRecursive Walker(Name, Context.BuiltinInfo);
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
Walker.TraverseFunctionDecl(const_cast<FunctionDecl*>(FD));
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
return Walker.Result;
}
Try harder to not inline dllimport functions referencing non-dllimport functions In r246338, code was added to check for this, but it failed to take into account implicit destructor invocations because those are not reflected in the AST. This adds a separate check for them. llvm-svn: 281395
2016-09-14 05:08:20 +08:00
bool CodeGenModule::shouldEmitFunction(GlobalDecl GD) {
[ms-cxxabi] Thread GlobalDecls through to CodeGenModule::getFunctionLinkage. This is so that we can give destructor variants different linkage later. Differential Revision: http://llvm-reviews.chandlerc.com/D819 llvm-svn: 183324
2013-06-06 01:49:37 +08:00
if (getFunctionLinkage(GD) != llvm::Function::AvailableExternallyLinkage)
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
return true;
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *F = cast<FunctionDecl>(GD.getDecl());
Attr: Remove ForceInline The __forceinline keyword's semantics are now recast as AlwaysInline and the kw___forceinline token has its language mode set for KEYMS. This preserves the semantics of the previous implementation but with less duplication of code. llvm-svn: 202131
2014-02-25 17:53:29 +08:00
if (CodeGenOpts.OptimizationLevel == 0 && !F->hasAttr<AlwaysInlineAttr>())
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
return false;
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
if (F->hasAttr<DLLImportAttr>()) {
// Check whether it would be safe to inline this dllimport function.
DLLImportFunctionVisitor Visitor;
Visitor.TraverseFunctionDecl(const_cast<FunctionDecl*>(F));
if (!Visitor.SafeToInline)
return false;
Try harder to not inline dllimport functions referencing non-dllimport functions In r246338, code was added to check for this, but it failed to take into account implicit destructor invocations because those are not reflected in the AST. This adds a separate check for them. llvm-svn: 281395
2016-09-14 05:08:20 +08:00
if (const CXXDestructorDecl *Dtor = dyn_cast<CXXDestructorDecl>(F)) {
// Implicit destructor invocations aren't captured in the AST, so the
// check above can't see them. Check for them manually here.
for (const Decl *Member : Dtor->getParent()->decls())
if (isa<FieldDecl>(Member))
if (HasNonDllImportDtor(cast<FieldDecl>(Member)->getType()))
return false;
for (const CXXBaseSpecifier &B : Dtor->getParent()->bases())
if (HasNonDllImportDtor(B.getType()))
return false;
}
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
2015-08-29 05:47:01 +08:00
}
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
// PR9614. Avoid cases where the source code is lying to us. An available
// externally function should have an equivalent function somewhere else,
// but a function that calls itself is clearly not equivalent to the real
// implementation.
// This happens in glibc's btowc and in some configure checks.
Extend the fix for PR9614 to handle inline asm in the outer decl and the inner decl being a builtin. This is needed to support the glibc headers in fedora 16 (2.14). llvm-svn: 146867
2011-12-19 22:41:01 +08:00
return !isTriviallyRecursive(F);
Fix pr9614 by not emitting an available_externally function when it calls itself via an asm label. available_externally functions are supposed to correspond to an external function, and that is not the case in the examples in pr9614. llvm-svn: 143049
2011-10-27 04:41:06 +08:00
}
Emit available_externally vtables opportunistically Summary: We can emit vtable definition having inline function if they are all emitted. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33437 llvm-svn: 304394
2017-06-01 16:04:05 +08:00
bool CodeGenModule::shouldOpportunisticallyEmitVTables() {
return CodeGenOpts.OptimizationLevel > 0;
}
Save another call to GetAddrOfFunction. Thread an optional GV down to EmitGlobalFunctionDefinition so that it can avoid the lookup when we already know the corresponding llvm global value. llvm-svn: 196789
2013-12-10 00:01:03 +08:00
void CodeGenModule::EmitGlobalDefinition(GlobalDecl GD, llvm::GlobalValue *GV) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *D = cast<ValueDecl>(GD.getDecl());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
PrettyStackTraceDecl CrashInfo(const_cast<ValueDecl *>(D), D->getLocation(),
Add a PrettyStackTraceDecl in CodeGenModule::EmitGlobalDefinition. llvm-svn: 85237
2009-10-27 22:32:27 +08:00
Context.getSourceManager(),
"Generating code for declaration");
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
[ms-cxxabi] Thread GlobalDecls through to CodeGenModule::getFunctionLinkage. This is so that we can give destructor variants different linkage later. Differential Revision: http://llvm-reviews.chandlerc.com/D819 llvm-svn: 183324
2013-06-06 01:49:37 +08:00
if (isa<FunctionDecl>(D)) {
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
// At -O0, don't generate IR for functions with available_externally
Reinstate the optimization suppressing available_externally functions at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
2010-07-13 14:02:28 +08:00
// linkage.
[ms-cxxabi] Thread GlobalDecls through to CodeGenModule::getFunctionLinkage. This is so that we can give destructor variants different linkage later. Differential Revision: http://llvm-reviews.chandlerc.com/D819 llvm-svn: 183324
2013-06-06 01:49:37 +08:00
if (!shouldEmitFunction(GD))
Reinstate the optimization suppressing available_externally functions at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
2010-07-13 14:02:28 +08:00
return;
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Method = dyn_cast<CXXMethodDecl>(D)) {
Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 . llvm-svn: 130993
2011-05-07 01:27:27 +08:00
// Make sure to emit the definition(s) before we emit the thunks.
// This is necessary for the generation of certain thunks.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CD = dyn_cast<CXXConstructorDecl>(Method))
Move emitCXXStructor to CGCXXABI. A followup patch will address the code duplication. llvm-svn: 217807
2014-09-16 03:20:10 +08:00
ABI->emitCXXStructor(CD, getFromCtorType(GD.getCtorType()));
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
else if (const auto *DD = dyn_cast<CXXDestructorDecl>(Method))
Move emitCXXStructor to CGCXXABI. A followup patch will address the code duplication. llvm-svn: 217807
2014-09-16 03:20:10 +08:00
ABI->emitCXXStructor(DD, getFromDtorType(GD.getDtorType()));
Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 . llvm-svn: 130993
2011-05-07 01:27:27 +08:00
else
Save another call to GetAddrOfFunction. Thread an optional GV down to EmitGlobalFunctionDefinition so that it can avoid the lookup when we already know the corresponding llvm global value. llvm-svn: 196789
2013-12-10 00:01:03 +08:00
EmitGlobalFunctionDefinition(GD, GV);
Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 . llvm-svn: 130993
2011-05-07 01:27:27 +08:00
Reinstate the optimization suppressing available_externally functions at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
2010-07-13 14:02:28 +08:00
if (Method->isVirtual())
getVTables().EmitThunks(GD);
Always emit associated thunks when emitting the function itself. Remove getVtableAddressPoint, it's not used. llvm-svn: 99252
2010-03-23 12:31:31 +08:00
Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 . llvm-svn: 130993
2011-05-07 01:27:27 +08:00
return;
Reinstate the optimization suppressing available_externally functions at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
2010-07-13 14:02:28 +08:00
}
unbreak tests. llvm-svn: 101153
2010-04-14 01:57:11 +08:00
Save another call to GetAddrOfFunction. Thread an optional GV down to EmitGlobalFunctionDefinition so that it can avoid the lookup when we already know the corresponding llvm global value. llvm-svn: 196789
2013-12-10 00:01:03 +08:00
return EmitGlobalFunctionDefinition(GD, GV);
Reinstate the optimization suppressing available_externally functions at -O0. The only change from the previous patch is that we don't try to generate virtual method thunks for an available_externally function. llvm-svn: 108230
2010-07-13 14:02:28 +08:00
}
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *VD = dyn_cast<VarDecl>(D))
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
return EmitGlobalVarDefinition(VD, !VD->hasDefinition());
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Invalid argument to EmitGlobalDefinition()");
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
}
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
static void ReplaceUsesOfNonProtoTypeWithRealFunction(llvm::GlobalValue *Old,
llvm::Function *NewFn);
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// GetOrCreateLLVMFunction - If the specified mangled name is not in the
/// module, create and return an llvm Function with the specified type. If there
/// is something in the module with the specified name, return it potentially
/// bitcasted to the right type.
///
/// If D is non-null, it specifies a decl that correspond to this. This is used
/// to set the attributes on the function when it is first created.
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
StringRef MangledName, llvm::Type *Ty, GlobalDecl GD, bool ForVTable,
bool DontDefer, bool IsThunk, llvm::AttributeList ExtraAttrs,
ForDefinition_t IsForDefinition) {
Rename D to GD to match the type, which is GlobalDecl Now we can save GD.getDecl() in D and shorten some casts. llvm-svn: 186826
2013-07-22 21:07:10 +08:00
const Decl *D = GD.getDecl();
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
// Lookup the entry, lazily creating it if necessary.
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
if (Entry) {
Reduce duplicated hash map lookups. llvm-svn: 162361
2012-08-22 23:37:55 +08:00
if (WeakRefReferences.erase(Entry)) {
Rename D to GD to match the type, which is GlobalDecl Now we can save GD.getDecl() in D and shorten some casts. llvm-svn: 186826
2013-07-22 21:07:10 +08:00
const FunctionDecl *FD = cast_or_null<FunctionDecl>(D);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
if (FD && !FD->hasAttr<WeakAttr>())
Always emit associated thunks when emitting the function itself. Remove getVtableAddressPoint, it's not used. llvm-svn: 99252
2010-03-23 12:31:31 +08:00
Entry->setLinkage(llvm::Function::ExternalLinkage);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
}
Better codegen support for DLL attributes being dropped after the first declaration (PR20792) For the following code: __declspec(dllimport) int f(int x); int user(int x) { return f(x); } int f(int x) { return 1; } Clang will drop the dllimport attribute in the AST, but CodeGen would have already put it on the LLVM::Function, and that would never get updated. (The same thing happens for global variables.) This makes Clang check dropped DLL attribute case each time the LLVM object is referenced. This isn't perfect, because we will still get it wrong if the function is never referenced by codegen after the attribute is dropped, but this handles the common cases and makes us not fail in the verifier. llvm-svn: 216699
2014-08-29 08:16:06 +08:00
// Handle dropped DLL attributes.
if (D && !D->hasAttr<DLLImportAttr>() && !D->hasAttr<DLLExportAttr>())
Entry->setDLLStorageClass(llvm::GlobalValue::DefaultStorageClass);
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
// If there are two attempts to define the same mangled name, issue an
// error.
if (IsForDefinition && !Entry->isDeclaration()) {
GlobalDecl OtherGD;
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
// Check that GD is not yet in DiagnosedConflictingDefinitions is required
// to make sure that we issue an error only once.
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
if (lookupRepresentativeDecl(MangledName, OtherGD) &&
(GD.getCanonicalDecl().getDecl() !=
OtherGD.getCanonicalDecl().getDecl()) &&
DiagnosedConflictingDefinitions.insert(GD).second) {
getDiags().Report(D->getLocation(),
diag::err_duplicate_mangled_name);
getDiags().Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
}
}
if ((isa<llvm::Function>(Entry) || isa<llvm::GlobalAlias>(Entry)) &&
(Entry->getType()->getElementType() == Ty)) {
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
return Entry;
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
// Make sure the result is of the correct type.
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
// (If function is requested for a definition, we always need to create a new
// function, not just return a bitcast.)
if (!IsForDefinition)
return llvm::ConstantExpr::getBitCast(Entry, Ty->getPointerTo());
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rearrange function to avoid recursive use-after-free. llvm-svn: 86516
2009-11-09 13:07:37 +08:00
// This function doesn't have a complete type (for example, the return
// type is an incomplete struct). Use a fake type instead, and make
// sure not to try to set attributes.
bool IsIncompleteFunction = false;
Properly pass the address of a lazily-generated function declaration with incomplete type. Fixes PR6911. llvm-svn: 102473
2010-04-28 08:00:30 +08:00
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::FunctionType *FTy;
Properly pass the address of a lazily-generated function declaration with incomplete type. Fixes PR6911. llvm-svn: 102473
2010-04-28 08:00:30 +08:00
if (isa<llvm::FunctionType>(Ty)) {
FTy = cast<llvm::FunctionType>(Ty);
} else {
Use arrays and SmallVectors instead of std::vectors when building function types. Also, cache a translation of 'void' in CGM and provide a ptrdiff_t alias. No functionality change. llvm-svn: 131373
2011-05-15 09:53:33 +08:00
FTy = llvm::FunctionType::get(VoidTy, false);
Rearrange function to avoid recursive use-after-free. llvm-svn: 86516
2009-11-09 13:07:37 +08:00
IsIncompleteFunction = true;
}
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
llvm::Function *F =
llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
Entry ? StringRef() : MangledName, &getModule());
// If we already created a function with the same mangled name (but different
// type) before, take its name and add it to the list of functions to be
// replaced with F at the end of CodeGen.
//
// This happens if there is a prototype for a function (e.g. "int f()") and
// then a definition of a different type (e.g. "int f(int x)").
if (Entry) {
F->takeName(Entry);
// This might be an implementation of a function without a prototype, in
// which case, try to do special replacement of calls which match the new
// prototype. The really key thing here is that we also potentially drop
// arguments from the call site so as to make a direct call, which makes the
// inliner happier and suppresses a number of optimizer warnings (!) about
// dropping arguments.
if (!Entry->use_empty()) {
ReplaceUsesOfNonProtoTypeWithRealFunction(Entry, F);
Entry->removeDeadConstantUsers();
}
llvm::Constant *BC = llvm::ConstantExpr::getBitCast(
F, Entry->getType()->getElementType()->getPointerTo());
addGlobalValReplacement(Entry, BC);
}
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
assert(F->getName() == MangledName && "name was uniqued!");
Rename D to GD to match the type, which is GlobalDecl Now we can save GD.getDecl() in D and shorten some casts. llvm-svn: 186826
2013-07-22 21:07:10 +08:00
if (D)
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
SetFunctionAttributes(GD, F, IsIncompleteFunction, IsThunk,
IsForDefinition);
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
if (ExtraAttrs.hasAttributes(llvm::AttributeList::FunctionIndex)) {
llvm::AttrBuilder B(ExtraAttrs, llvm::AttributeList::FunctionIndex);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
F->addAttributes(llvm::AttributeList::FunctionIndex, B);
Use the AttributeSet when adding multiple attributes and an Attribute::AttrKind when adding a single attribute to the function. llvm-svn: 173211
2013-01-23 08:21:06 +08:00
}
Rearrange function to avoid recursive use-after-free. llvm-svn: 86516
2009-11-09 13:07:37 +08:00
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
if (!DontDefer) {
// All MSVC dtors other than the base dtor are linkonce_odr and delegate to
// each other bottoming out with the base dtor. Therefore we emit non-base
// dtors on usage, even if there is no dtor definition in the TU.
if (D && isa<CXXDestructorDecl>(D) &&
getCXXABI().useThunkForDtorVariant(cast<CXXDestructorDecl>(D),
GD.getDtorType()))
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(GD);
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
// This is the first use or definition of a mangled name. If there is a
// deferred decl with this name, remember that we need to emit it at the end
// of the file.
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
auto DDI = DeferredDecls.find(MangledName);
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
if (DDI != DeferredDecls.end()) {
// Move the potentially referenced deferred decl to the
// DeferredDeclsToEmit list, and remove it from DeferredDecls (since we
// don't need it anymore).
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(DDI->second);
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
DeferredDecls.erase(DDI);
// Otherwise, there are cases we have to worry about where we're
// using a declaration for which we must emit a definition but where
// we might not find a top-level definition:
// - member functions defined inline in their classes
// - friend functions defined inline in some class
// - special member functions with implicit definitions
// If we ever change our AST traversal to walk into class methods,
// this will be unnecessary.
//
// We also don't emit a definition for a function if it's going to be an
[modules] Remove IRGen special case for emitting implicit special members if they're somehow missing a body. Looks like this was left behind when the loop was generalized, and it's not been problematic before because without modules, a used, implicit special member function declaration must be a definition. This was resulting in us trying to emit a constructor declaration rather than a definition, and producing a constructor missing its member initializers. llvm-svn: 214473
2014-08-01 09:56:39 +08:00
// entry in a vtable, unless it's already marked as used.
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
} else if (getLangOpts().CPlusPlus && D) {
// Look for a declaration that's lexically in a record.
[modules] Remove IRGen special case for emitting implicit special members if they're somehow missing a body. Looks like this was left behind when the loop was generalized, and it's not been problematic before because without modules, a used, implicit special member function declaration must be a definition. This was resulting in us trying to emit a constructor declaration rather than a definition, and producing a constructor missing its member initializers. llvm-svn: 214473
2014-08-01 09:56:39 +08:00
for (const auto *FD = cast<FunctionDecl>(D)->getMostRecentDecl(); FD;
FD = FD->getPreviousDecl()) {
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
if (isa<CXXRecordDecl>(FD->getLexicalDeclContext())) {
[modules] Remove IRGen special case for emitting implicit special members if they're somehow missing a body. Looks like this was left behind when the loop was generalized, and it's not been problematic before because without modules, a used, implicit special member function declaration must be a definition. This was resulting in us trying to emit a constructor declaration rather than a definition, and producing a constructor missing its member initializers. llvm-svn: 214473
2014-08-01 09:56:39 +08:00
if (FD->doesThisDeclarationHaveABody()) {
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(GD.getWithDecl(FD));
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
break;
}
Set the "implicitly inline" bit on a method as soon as we see a definition within the class. Teach IR gen to look for function definitions in record lexical contexts when deciding whether to emit a function whose address was taken. Fixes PR8789. llvm-svn: 121833
2010-12-15 12:00:32 +08:00
}
[modules] Remove IRGen special case for emitting implicit special members if they're somehow missing a body. Looks like this was left behind when the loop was generalized, and it's not been problematic before because without modules, a used, implicit special member function declaration must be a definition. This was resulting in us trying to emit a constructor declaration rather than a definition, and producing a constructor missing its member initializers. llvm-svn: 214473
2014-08-01 09:56:39 +08:00
}
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
}
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Properly pass the address of a lazily-generated function declaration with incomplete type. Fixes PR6911. llvm-svn: 102473
2010-04-28 08:00:30 +08:00
// Make sure the result is of the requested type.
if (!IsIncompleteFunction) {
assert(F->getType()->getElementType() == Ty);
return F;
}
clang side to match the LLVM IR type system rewrite patch. llvm-svn: 134831
2011-07-10 01:41:47 +08:00
llvm::Type *PTy = llvm::PointerType::getUnqual(Ty);
Properly pass the address of a lazily-generated function declaration with incomplete type. Fixes PR6911. llvm-svn: 102473
2010-04-28 08:00:30 +08:00
return llvm::ConstantExpr::getBitCast(F, PTy);
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
}
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// GetAddrOfFunction - Return the address of the given function. If Ty is
/// non-null, then this function will use the specified type if it has to
/// create it (this occurs when we see a definition of the function).
push GlobalDecl through enough of the CodeGenModule interfaces to allow us to support generation of deferred ctors/dtors. It looks like codegen isn't emitting a call to the dtor in member-functions.cpp:test2, but when it does, its body should get emitted. llvm-svn: 71594
2009-05-13 05:21:08 +08:00
llvm::Constant *CodeGenModule::GetAddrOfFunction(GlobalDecl GD,
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *Ty,
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
bool ForVTable,
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
bool DontDefer,
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
ForDefinition_t IsForDefinition) {
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
// If there was no specific requested type, just convert it now.
Add the `pass_object_size` attribute to clang. `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
2015-12-03 05:58:08 +08:00
if (!Ty) {
const auto *FD = cast<FunctionDecl>(GD.getDecl());
auto CanonTy = Context.getCanonicalType(FD->getType());
Ty = getTypes().ConvertFunctionType(CanonTy, FD);
}
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef MangledName = getMangledName(GD);
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
return GetOrCreateLLVMFunction(MangledName, Ty, GD, ForVTable, DontDefer,
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
/*IsThunk=*/false, llvm::AttributeList(),
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
IsForDefinition);
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
}
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
static const FunctionDecl *
GetRuntimeFunctionDecl(ASTContext &C, StringRef Name) {
TranslationUnitDecl *TUDecl = C.getTranslationUnitDecl();
DeclContext *DC = TranslationUnitDecl::castToDeclContext(TUDecl);
IdentifierInfo &CII = C.Idents.get(Name);
for (const auto &Result : DC->lookup(&CII))
if (const auto FD = dyn_cast<FunctionDecl>(Result))
return FD;
if (!C.getLangOpts().CPlusPlus)
return nullptr;
// Demangle the premangled name from getTerminateFn()
IdentifierInfo &CXXII =
(Name == "_ZSt9terminatev" || Name == "\01?terminate@@YAXXZ")
? C.Idents.get("terminate")
: C.Idents.get(Name);
for (const auto &N : {"__cxxabiv1", "std"}) {
IdentifierInfo &NS = C.Idents.get(N);
for (const auto &Result : DC->lookup(&NS)) {
NamespaceDecl *ND = dyn_cast<NamespaceDecl>(Result);
if (auto LSD = dyn_cast<LinkageSpecDecl>(Result))
for (const auto &Result : LSD->lookup(&NS))
if ((ND = dyn_cast<NamespaceDecl>(Result)))
break;
if (ND)
for (const auto &Result : ND->lookup(&CXXII))
if (const auto *FD = dyn_cast<FunctionDecl>(Result))
return FD;
}
}
return nullptr;
}
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// CreateRuntimeFunction - Create a new runtime function with the specified
/// type and name.
llvm::Constant *
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
CodeGenModule::CreateRuntimeFunction(llvm::FunctionType *FTy, StringRef Name,
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
llvm::AttributeList ExtraAttrs,
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
bool Local) {
Avoid adding some decls to DeferredDeclsToEmit. Before this patch GetOrCreateLLVMFunction would add a decl to DeferredDeclsToEmit even when it was being called by the function trying to emit that decl. llvm-svn: 196753
2013-12-09 12:29:47 +08:00
llvm::Constant *C =
GetOrCreateLLVMFunction(Name, FTy, GlobalDecl(), /*ForVTable=*/false,
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
/*DontDefer=*/false, /*IsThunk=*/false,
ExtraAttrs);
if (auto *F = dyn_cast<llvm::Function>(C)) {
if (F->empty()) {
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
F->setCallingConv(getRuntimeCC());
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
if (!Local && getTriple().isOSBinFormatCOFF() &&
CodeGenCXX: no default dllimport storage for mingw GNU frontends don't have options like /MT, /MD This fixes a few link error regressions with libc++ and libc++abi Reviewers: rnk, mstorsjo, compnerd Differential Revision: https://reviews.llvm.org/D33620 llvm-svn: 317398
2017-11-04 10:15:49 +08:00
!getCodeGenOpts().LTOVisibilityPublicStd &&
!getTriple().isWindowsGNUEnvironment()) {
CodeGen: fix runtime function dll storage Properly attribute DLL storage to runtime functions. When generating the runtime function, scan for an existing declaration which may provide an explicit declaration (local storage) or a DLL import or export storage from the user. Honour that if available. Otherwise, if building with a local visibility of the public or standard namespaces (-flto-visibility-public-std), give the symbols local storage (it indicates a /MT[d] link, so static runtime). Otherwise, assume that the link is dynamic, and give the runtime function dllimport storage. This allows for implementations to get the correct storage as long as they are properly declared, the user to override the import storage, and in case no explicit storage is given, use of the import storage. llvm-svn: 289776
2016-12-15 14:59:05 +08:00
const FunctionDecl *FD = GetRuntimeFunctionDecl(Context, Name);
if (!FD || FD->hasAttr<DLLImportAttr>()) {
F->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
F->setLinkage(llvm::GlobalValue::ExternalLinkage);
}
}
}
}
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
return C;
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
}
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
Fix invalid calling convention used for libcalls on ARM. ARM ABI specifies that all the libcalls use soft FP ABI (even hard FP binaries). These days clang emits _mulsc3 / _muldc3 calls with default (C) calling convention which would be translated into AAPCS_VFP LLVM calling and thus the result of complex multiplication will be bogus. Introduce a way for a target to specify explicitly calling convention for libcalls. Right now this is temporary correctness fix. Ultimately, we'll end with intrinsic for complex multiplication and all calling convention decisions for libcalls will be put into backend. llvm-svn: 223123
2014-12-03 00:04:58 +08:00
/// CreateBuiltinFunction - Create a new builtin function with the specified
/// type and name.
llvm::Constant *
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
CodeGenModule::CreateBuiltinFunction(llvm::FunctionType *FTy, StringRef Name,
llvm::AttributeList ExtraAttrs) {
Fix invalid calling convention used for libcalls on ARM. ARM ABI specifies that all the libcalls use soft FP ABI (even hard FP binaries). These days clang emits _mulsc3 / _muldc3 calls with default (C) calling convention which would be translated into AAPCS_VFP LLVM calling and thus the result of complex multiplication will be bogus. Introduce a way for a target to specify explicitly calling convention for libcalls. Right now this is temporary correctness fix. Ultimately, we'll end with intrinsic for complex multiplication and all calling convention decisions for libcalls will be put into backend. llvm-svn: 223123
2014-12-03 00:04:58 +08:00
llvm::Constant *C =
GetOrCreateLLVMFunction(Name, FTy, GlobalDecl(), /*ForVTable=*/false,
/*DontDefer=*/false, /*IsThunk=*/false, ExtraAttrs);
if (auto *F = dyn_cast<llvm::Function>(C))
if (F->empty())
F->setCallingConv(getBuiltinCC());
return C;
}
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
/// isTypeConstant - Determine whether an object of this type can be emitted
/// as a constant.
///
/// If ExcludeCtor is true, the duration when the object's constructor runs
/// will not be considered. The caller will need to verify that the object is
/// not written to during its construction.
bool CodeGenModule::isTypeConstant(QualType Ty, bool ExcludeCtor) {
if (!Ty.isConstant(Context) && !Ty->isReferenceType())
Fix for PR5714: make sure globals that will be modified aren't marked const. llvm-svn: 91156
2009-12-12 05:23:03 +08:00
return false;
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (Context.getLangOpts().CPlusPlus) {
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
if (const CXXRecordDecl *Record
= Context.getBaseElementType(Ty)->getAsCXXRecordDecl())
return ExcludeCtor && !Record->hasMutableFields() &&
Record->hasTrivialDestructor();
Fix for PR5714: make sure globals that will be modified aren't marked const. llvm-svn: 91156
2009-12-12 05:23:03 +08:00
}
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
Fix for PR5714: make sure globals that will be modified aren't marked const. llvm-svn: 91156
2009-12-12 05:23:03 +08:00
return true;
}
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// GetOrCreateLLVMGlobal - If the specified mangled name is not in the module,
/// create and return an llvm GlobalVariable with the specified type. If there
/// is something in the module with the specified name, return it potentially
/// bitcasted to the right type.
///
/// If D is non-null, it specifies a decl that correspond to this. This is used
/// to set the attributes on the global when it is first created.
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
///
/// If IsForDefinition is true, it is guranteed that an actual global with
/// type Ty will be returned, not conversion of a variable with the same
/// mangled name but some other type.
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
llvm::Constant *
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
CodeGenModule::GetOrCreateLLVMGlobal(StringRef MangledName,
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::PointerType *Ty,
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
const VarDecl *D,
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
ForDefinition_t IsForDefinition) {
Change CodeGen of global decls to key off of the name (instead of having multiple bindings from all the possible decls which conceptually map to the same global). - This eliminates CodeGen depending on the LLVM module for name lookup. - This also eliminates the need for ReplaceMapValuesWith (hurrah). - This handles lookups for FunctionDecls correctly in the presence of aliases, this was previously broken. - WIP: Can still clean up & unify variable and function emission. llvm-svn: 54382
2008-08-06 07:31:02 +08:00
// Lookup the entry, lazily creating it if necessary.
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
simplify some more code. llvm-svn: 67439
2009-03-21 16:03:33 +08:00
if (Entry) {
Reduce duplicated hash map lookups. llvm-svn: 162361
2012-08-22 23:37:55 +08:00
if (WeakRefReferences.erase(Entry)) {
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
if (D && !D->hasAttr<WeakAttr>())
Always emit associated thunks when emitting the function itself. Remove getVtableAddressPoint, it's not used. llvm-svn: 99252
2010-03-23 12:31:31 +08:00
Entry->setLinkage(llvm::Function::ExternalLinkage);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
}
Better codegen support for DLL attributes being dropped after the first declaration (PR20792) For the following code: __declspec(dllimport) int f(int x); int user(int x) { return f(x); } int f(int x) { return 1; } Clang will drop the dllimport attribute in the AST, but CodeGen would have already put it on the LLVM::Function, and that would never get updated. (The same thing happens for global variables.) This makes Clang check dropped DLL attribute case each time the LLVM object is referenced. This isn't perfect, because we will still get it wrong if the function is never referenced by codegen after the attribute is dropped, but this handles the common cases and makes us not fail in the verifier. llvm-svn: 216699
2014-08-29 08:16:06 +08:00
// Handle dropped DLL attributes.
if (D && !D->hasAttr<DLLImportAttr>() && !D->hasAttr<DLLExportAttr>())
Entry->setDLLStorageClass(llvm::GlobalValue::DefaultStorageClass);
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
if (Entry->getType() == Ty)
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
return Entry;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
// If there are two attempts to define the same mangled name, issue an
// error.
if (IsForDefinition && !Entry->isDeclaration()) {
GlobalDecl OtherGD;
const VarDecl *OtherD;
// Check that D is not yet in DiagnosedConflictingDefinitions is required
// to make sure that we issue an error only once.
Check for nullptr argument. Addresses static analysis report in PR15492. Differential Revision: http://reviews.llvm.org/D20141 llvm-svn: 270086
2016-05-20 02:00:18 +08:00
if (D && lookupRepresentativeDecl(MangledName, OtherGD) &&
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
(D->getCanonicalDecl() != OtherGD.getCanonicalDecl().getDecl()) &&
(OtherD = dyn_cast<VarDecl>(OtherGD.getDecl())) &&
OtherD->hasInit() &&
DiagnosedConflictingDefinitions.insert(D).second) {
getDiags().Report(D->getLocation(),
diag::err_duplicate_mangled_name);
getDiags().Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
}
}
simplify some more code. llvm-svn: 67439
2009-03-21 16:03:33 +08:00
// Make sure the result is of the correct type.
Fix test failures after addrspacecast added. Bitcasts between address spaces are no longer allowed. llvm-svn: 194765
2013-11-15 10:19:52 +08:00
if (Entry->getType()->getAddressSpace() != Ty->getAddressSpace())
return llvm::ConstantExpr::getAddrSpaceCast(Entry, Ty);
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
// (If global is requested for a definition, we always need to create a new
// global, not just return a bitcast.)
if (!IsForDefinition)
return llvm::ConstantExpr::getBitCast(Entry, Ty);
simplify some more code. llvm-svn: 67439
2009-03-21 16:03:33 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
auto AddrSpace = GetGlobalVarAddressSpace(D);
auto TargetAddrSpace = getContext().getTargetAddressSpace(AddrSpace);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = new llvm::GlobalVariable(
getModule(), Ty->getElementType(), false,
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::GlobalValue::ExternalLinkage, nullptr, MangledName, nullptr,
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
llvm::GlobalVariable::NotThreadLocal, TargetAddrSpace);
When we decide to output a deferred decl, remember the llvm GlobalValue. We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already emitted or not. This fixes a 2010 TODO. llvm-svn: 196785
2013-12-09 22:59:08 +08:00
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
// If we already created a global with the same mangled name (but different
// type) before, take its name and remove it from its parent.
if (Entry) {
GV->takeName(Entry);
if (!Entry->use_empty()) {
llvm::Constant *NewPtrForOldDecl =
llvm::ConstantExpr::getBitCast(GV, Entry->getType());
Entry->replaceAllUsesWith(NewPtrForOldDecl);
}
Entry->eraseFromParent();
}
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
// This is the first use or definition of a mangled name. If there is a
// deferred decl with this name, remember that we need to emit it at the end
// of the file.
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
auto DDI = DeferredDecls.find(MangledName);
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
if (DDI != DeferredDecls.end()) {
// Move the potentially referenced deferred decl to the DeferredDeclsToEmit
// list, and remove it from DeferredDecls (since we don't need it anymore).
Remove unneeded struct; NFC Summary: Unless I'm missing something, the DeferredGlobal struct's GV field is unused, removing which makes the struct itself trivial. Reviewers: rafael, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32691 llvm-svn: 301789
2017-05-01 14:12:13 +08:00
addDeferredDeclToEmit(DDI->second);
now that all the decl reference and creation stuff is going through two very simple places, reimplement the deferred decl emission logic to not be O(N^2), fixing PR3810. llvm-svn: 67447
2009-03-21 17:44:56 +08:00
DeferredDecls.erase(DDI);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify some more code. llvm-svn: 67439
2009-03-21 16:03:33 +08:00
// Handle things which are present even on external declarations.
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
if (D) {
Reflow some comments. llvm-svn: 71937
2009-05-16 15:57:57 +08:00
// FIXME: This code is overly simple and should be merged with other global
// handling.
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
GV->setConstant(isTypeConstant(D->getType(), false));
Bug fix, __private_extern__ globals were always introducing a definition. llvm-svn: 62139
2009-01-13 10:25:00 +08:00
Provide alignment info on LLVM external symbols Code in CodeGenModule::GetOrCreateLLVMGlobal that sets up GlobalValue object for LLVM external symbols has this comment: // FIXME: This code is overly simple and should be merged with other global // handling. One part does seems to be "overly simple" currently is that this code never sets any alignment info on the GlobalValue, so that the emitted IR does not have any align attribute on external globals. This can lead to unnecessarily inefficient code generation. This patch adds a GV->setAlignment call to set alignment info. llvm-svn: 235396
2015-04-22 01:27:59 +08:00
GV->setAlignment(getContext().getDeclAlign(D).getQuantity());
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
setLinkageForGV(GV, D);
setGlobalVisibility(GV, D, NotForDefinition);
PR3853: Add CodeGen support for __thread. llvm-svn: 69545
2009-04-20 05:05:03 +08:00
Implement CodeGen for C++11 thread_local, following the Itanium ABI specification as discussed on cxx-abi-dev. llvm-svn: 179858
2013-04-20 00:42:07 +08:00
if (D->getTLSKind()) {
Don't emit _ZTW wrappers for TLS variables which don't use the C++ thread_local keyword. llvm-svn: 180004
2013-04-22 16:06:17 +08:00
if (D->getTLSKind() == VarDecl::TLS_Dynamic)
Fix use-after-free when a C++ thread_local variable gets replaced (because its type changes when the initializer is attached). Don't hold onto the GlobalVariable*; recompute it from the VarDecl* instead. llvm-svn: 254359
2015-12-01 09:10:48 +08:00
CXXThreadLocals.push_back(D);
Add -ftls-model command-line flag. This allows for setting the default TLS model. (PR9788) llvm-svn: 159336
2012-06-28 16:01:44 +08:00
setTLSMode(GV, *D);
Implement CodeGen for C++11 thread_local, following the Itanium ABI specification as discussed on cxx-abi-dev. llvm-svn: 179858
2013-04-20 00:42:07 +08:00
}
[-cxx-abi microsoft] Emit linkonce_odr definitions for declarations of static data members with inline initializers (PR17689) This makes Clang emit a linkonce_odr definition for 'val' in the code below, to be compatible with MSVC-compiled code: struct Foo { static const int val = 1; }; Differential Revision: http://llvm-reviews.chandlerc.com/D2233 llvm-svn: 195283
2013-11-21 08:15:56 +08:00
// If required by the ABI, treat declarations of static data members with
// inline initializers as definitions.
MS compatibility: always emit dllexported in-class initialized static data members (PR20140) This makes us emit dllexported in-class initialized static data members (which are treated as definitions in MSVC), even when they're not referenced. It also makes their special linkage reflected in the GVA linkage instead of getting massaged in CodeGen. Differential Revision: http://reviews.llvm.org/D4563 llvm-svn: 213304
2014-07-18 04:25:23 +08:00
if (getContext().isMSStaticDataMemberInlineDefinition(D)) {
[-cxx-abi microsoft] Emit linkonce_odr definitions for declarations of static data members with inline initializers (PR17689) This makes Clang emit a linkonce_odr definition for 'val' in the code below, to be compatible with MSVC-compiled code: struct Foo { static const int val = 1; }; Differential Revision: http://llvm-reviews.chandlerc.com/D2233 llvm-svn: 195283
2013-11-21 08:15:56 +08:00
EmitGlobalVarDefinition(D);
MS compatibility: always emit dllexported in-class initialized static data members (PR20140) This makes us emit dllexported in-class initialized static data members (which are treated as definitions in MSVC), even when they're not referenced. It also makes their special linkage reflected in the GVA linkage instead of getting massaged in CodeGen. Differential Revision: http://reviews.llvm.org/D4563 llvm-svn: 213304
2014-07-18 04:25:23 +08:00
}
XCore target: fix bug in dereferencing null pointer. Also add basic cpp ABI tests where they differ from C ABI output. llvm-svn: 207834
2014-05-02 17:33:30 +08:00
Emit section information for extern variables. Currently, if _attribute_((section())) is used for extern variables, section information is not emitted in generated IR when the variables are used. This is expected since sections are not generated for external linkage objects. However NiosII requires this information as it uses special GP-relative accesses for any objects that use attribute section (.sdata). GCC keeps this attribute in middle-end. This change emits the section information for all targets. Patch By: Elizabeth Andrews Differential Revision:https://reviews.llvm.org/D36487 llvm-svn: 314262
2017-09-27 07:42:34 +08:00
// Emit section information for extern variables.
if (D->hasExternalStorage()) {
if (const SectionAttr *SA = D->getAttr<SectionAttr>())
GV->setSection(SA->getName());
}
XCore target: fix bug in dereferencing null pointer. Also add basic cpp ABI tests where they differ from C ABI output. llvm-svn: 207834
2014-05-02 17:33:30 +08:00
// Handle XCore specific ABI requirements.
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
if (getTriple().getArch() == llvm::Triple::xcore &&
XCore target: fix bug in dereferencing null pointer. Also add basic cpp ABI tests where they differ from C ABI output. llvm-svn: 207834
2014-05-02 17:33:30 +08:00
D->getLanguageLinkage() == CLanguageLinkage &&
D->getType().isConstant(Context) &&
isExternallyVisible(D->getLinkageAndVisibility().getLinkage()))
GV->setSection(".cp.rodata");
Emit static constexpr member as available_externally definition By exposing the constant initializer, the optimizer can fold many of these constructs. This is a recommit of r311857 that was reverted in r311898 because an assert was hit when building Chromium. We have to take into account that the GlobalVariable may be first created with a different type than the initializer. This can happen for example when the variable is a struct with tail padding while the initializer does not have padding. In such case, the variable needs to be destroyed an replaced with a new one with the type of the initializer. Differential Revision: https://reviews.llvm.org/D34992 llvm-svn: 312512
2017-09-05 11:58:35 +08:00
// Check if we a have a const declaration with an initializer, we may be
// able to emit it as available_externally to expose it's value to the
// optimizer.
if (Context.getLangOpts().CPlusPlus && GV->hasExternalLinkage() &&
D->getType().isConstQualified() && !GV->hasInitializer() &&
!D->hasDefinition() && D->hasInit() && !D->hasAttr<DLLImportAttr>()) {
const auto *Record =
Context.getBaseElementType(D->getType())->getAsCXXRecordDecl();
bool HasMutableFields = Record && Record->hasMutableFields();
if (!HasMutableFields) {
const VarDecl *InitDecl;
const Expr *InitExpr = D->getAnyInitializer(InitDecl);
if (InitExpr) {
ConstantEmitter emitter(*this);
llvm::Constant *Init = emitter.tryEmitForInitializer(*InitDecl);
if (Init) {
auto *InitType = Init->getType();
if (GV->getType()->getElementType() != InitType) {
// The type of the initializer does not match the definition.
// This happens when an initializer has a different type from
// the type of the global (because of padding at the end of a
// structure for instance).
GV->setName(StringRef());
// Make a new global with the correct type, this is now guaranteed
// to work.
auto *NewGV = cast<llvm::GlobalVariable>(
GetAddrOfGlobalVar(D, InitType, IsForDefinition));
// Erase the old global, since it is no longer used.
cast<llvm::GlobalValue>(GV)->eraseFromParent();
GV = NewGV;
} else {
GV->setInitializer(Init);
GV->setConstant(true);
GV->setLinkage(llvm::GlobalValue::AvailableExternallyLinkage);
}
emitter.finalize(GV);
}
}
}
}
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Convert clang::LangAS to a strongly typed enum 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
2017-10-16 02:48:14 +08:00
LangAS ExpectedAS =
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
D ? D->getType().getAddressSpace()
Convert clang::LangAS to a strongly typed enum 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
2017-10-16 02:48:14 +08:00
: (LangOpts.OpenCL ? LangAS::opencl_global : LangAS::Default);
[CodeGen] Fold variable into assert. Avoids warnings in Release builds. llvm-svn: 307472
2017-07-08 22:14:57 +08:00
assert(getContext().getTargetAddressSpace(ExpectedAS) ==
Ty->getPointerAddressSpace());
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
if (AddrSpace != ExpectedAS)
return getTargetCodeGenInfo().performAddrSpaceCast(*this, GV, AddrSpace,
ExpectedAS, Ty);
Fix test failures after addrspacecast added. Bitcasts between address spaces are no longer allowed. llvm-svn: 194765
2013-11-15 10:19:52 +08:00
return GV;
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
}
Emit extern_weak when needed. - PR3629. llvm-svn: 65203
2009-02-21 08:24:10 +08:00
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
llvm::Constant *
CodeGenModule::GetAddrOfGlobal(GlobalDecl GD,
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
ForDefinition_t IsForDefinition) {
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
const Decl *D = GD.getDecl();
if (isa<CXXConstructorDecl>(D))
return getAddrOfCXXStructor(cast<CXXConstructorDecl>(D),
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
getFromCtorType(GD.getCtorType()),
/*FnInfo=*/nullptr, /*FnType=*/nullptr,
/*DontDefer=*/false, IsForDefinition);
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
else if (isa<CXXDestructorDecl>(D))
return getAddrOfCXXStructor(cast<CXXDestructorDecl>(D),
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
getFromDtorType(GD.getDtorType()),
/*FnInfo=*/nullptr, /*FnType=*/nullptr,
/*DontDefer=*/false, IsForDefinition);
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
else if (isa<CXXMethodDecl>(D)) {
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
auto FInfo = &getTypes().arrangeCXXMethodDeclaration(
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
cast<CXXMethodDecl>(D));
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
auto Ty = getTypes().GetFunctionType(*FInfo);
return GetAddrOfFunction(GD, Ty, /*ForVTable=*/false, /*DontDefer=*/false,
IsForDefinition);
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
} else if (isa<FunctionDecl>(D)) {
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
const CGFunctionInfo &FI = getTypes().arrangeGlobalDeclaration(GD);
llvm::FunctionType *Ty = getTypes().GetFunctionType(FI);
return GetAddrOfFunction(GD, Ty, /*ForVTable=*/false, /*DontDefer=*/false,
IsForDefinition);
} else
Deduplicate several GD.getDecl() calls into Decl * local variable. llvm-svn: 290495
2016-12-24 23:32:39 +08:00
return GetAddrOfGlobalVar(cast<VarDecl>(D), /*Ty=*/nullptr,
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
IsForDefinition);
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
}
Emit extern_weak when needed. - PR3629. llvm-svn: 65203
2009-02-21 08:24:10 +08:00
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
llvm::GlobalVariable *
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
CodeGenModule::CreateOrReplaceCXXRuntimeVariable(StringRef Name,
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *Ty,
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
llvm::GlobalValue::LinkageTypes Linkage) {
llvm::GlobalVariable *GV = getModule().getNamedGlobal(Name);
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::GlobalVariable *OldGV = nullptr;
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
if (GV) {
// Check if the variable has the right type.
if (GV->getType()->getElementType() == Ty)
return GV;
// Because C++ name mangling, the only way we can end up with an already
// existing global with the same name is if it has been declared extern "C".
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
assert(GV->isDeclaration() && "Declaration has wrong type!");
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
OldGV = GV;
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
// Create a new variable.
GV = new llvm::GlobalVariable(getModule(), Ty, /*isConstant=*/true,
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
Linkage, nullptr, Name);
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
if (OldGV) {
// Replace occurrences of the old variable if needed.
GV->takeName(OldGV);
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
if (!OldGV->use_empty()) {
llvm::Constant *NewPtrForOldDecl =
llvm::ConstantExpr::getBitCast(GV, OldGV->getType());
OldGV->replaceAllUsesWith(NewPtrForOldDecl);
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
OldGV->eraseFromParent();
}
Use a trivial comdat for C++ tables. This produces comdats for vtables, typeinfo, typeinfo names, and vtts. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226227
2015-01-16 07:18:01 +08:00
Revert r236879, "Do not emit thunks with available_externally linkage in comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
2015-05-10 05:10:07 +08:00
if (supportsCOMDAT() && GV->isWeakForLinker() &&
!GV->hasAvailableExternallyLinkage())
GV->setComdat(TheModule.getOrInsertComdat(GV->getName()));
Use a trivial comdat for C++ tables. This produces comdats for vtables, typeinfo, typeinfo names, and vtts. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226227
2015-01-16 07:18:01 +08:00
Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code). llvm-svn: 124537
2011-01-30 02:20:20 +08:00
return GV;
}
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// GetAddrOfGlobalVar - Return the llvm::Constant for the address of the
/// given global variable. If Ty is non-null and if the global doesn't exist,
Typo. llvm-svn: 154880
2012-04-17 07:55:04 +08:00
/// then it will be created with the specified type instead of whatever the
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
/// normal requested type would be. If IsForDefinition is true, it is guranteed
/// that an actual global with type Ty will be returned, not conversion of a
/// variable with the same mangled name but some other type.
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
llvm::Constant *CodeGenModule::GetAddrOfGlobalVar(const VarDecl *D,
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
llvm::Type *Ty,
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
ForDefinition_t IsForDefinition) {
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
assert(D->hasGlobalStorage() && "Not a global variable");
QualType ASTTy = D->getType();
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
if (!Ty)
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
Ty = getTypes().ConvertTypeForMem(ASTTy);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::PointerType *PTy =
Add support for language-specific address spaces. On top of that, add support for the OpenCL __private, __local, __constant and __global address spaces, as well as the __read_only, _read_write and __write_only image access specifiers. Patch originally by ARM; language-specific address space support by myself. llvm-svn: 127915
2011-03-19 06:38:29 +08:00
llvm::PointerType::get(Ty, getContext().getTargetAddressSpace(ASTTy));
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef MangledName = getMangledName(D);
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
return GetOrCreateLLVMGlobal(MangledName, PTy, D, IsForDefinition);
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
}
Support "asm" renaming of external symbols. - PR3698. llvm-svn: 66038
2009-03-05 01:31:19 +08:00
pull "runtime globals" into the same framework as other functions/global variables. No intended functionality change. llvm-svn: 67478
2009-03-23 05:03:39 +08:00
/// CreateRuntimeVariable - Create a new runtime global variable with the
/// specified type and name.
llvm::Constant *
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
CodeGenModule::CreateRuntimeVariable(llvm::Type *Ty,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef Name) {
Don't set unnamed_addr in CreateRuntimeVariable. This was fairly broken. For example, @__dso_handle would or would not get an unnamed_addr depending on how many global destructors were used in a translation unit. The consensus was that not every runtime variable is unnamed_addr and that __dso_handle handle should not be, so just don't add unnamed_addr in CreateRuntimeVariable. llvm-svn: 209484
2014-05-23 07:33:27 +08:00
return GetOrCreateLLVMGlobal(Name, llvm::PointerType::getUnqual(Ty), nullptr);
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
}
Defer generation of tentative definitions. - PR3980. - <rdar://problem/6762287> [irgen] crash when generating tentative definition of incomplete structure - This also avoids creating common definitions for things which are later overwritten. - XFAIL'ed external-defs.c, it isn't completing types properly yet. llvm-svn: 69231
2009-04-16 06:08:45 +08:00
void CodeGenModule::EmitTentativeDefinition(const VarDecl *D) {
assert(!D->getInit() && "Cannot emit definite definitions here!");
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
StringRef MangledName = getMangledName(D);
llvm::GlobalValue *GV = GetGlobalValue(MangledName);
// We already have a definition, not declaration, with the same mangled name.
// Emitting of declaration is not required (and actually overwrites emitted
// definition).
if (GV && !GV->isDeclaration())
return;
// If we have not seen a reference to this variable yet, place it into the
// deferred declarations table to be emitted if needed later.
if (!MustBeEmitted(D) && !GV) {
GlobalDecl doesn't have an explicit constructor anymore. llvm-svn: 81481
2009-09-11 07:43:36 +08:00
DeferredDecls[MangledName] = D;
Defer generation of tentative definitions. - PR3980. - <rdar://problem/6762287> [irgen] crash when generating tentative definition of incomplete structure - This also avoids creating common definitions for things which are later overwritten. - XFAIL'ed external-defs.c, it isn't completing types properly yet. llvm-svn: 69231
2009-04-16 06:08:45 +08:00
return;
Fix emission of static tentative definitions referenced from other static functions llvm-svn: 69699
2009-04-22 03:28:58 +08:00
}
// The tentative definition is the only definition.
Revert "[x86] Exclusion of incorrect include headers paths for MCU target" This reverts commit r254195. From the description, I suspect that the wrong patch was committed here, and this is causing assertion failures in EmitDeferred() when the global value ends up being a bitcast of a global. llvm-svn: 254823
2015-12-05 09:52:14 +08:00
EmitGlobalVarDefinition(D);
Defer generation of tentative definitions. - PR3980. - <rdar://problem/6762287> [irgen] crash when generating tentative definition of incomplete structure - This also avoids creating common definitions for things which are later overwritten. - XFAIL'ed external-defs.c, it isn't completing types properly yet. llvm-svn: 69231
2009-04-16 06:08:45 +08:00
}
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
CharUnits CodeGenModule::GetTargetTypeStoreSize(llvm::Type *Ty) const {
LLVM API Change: the Module always owns the DataLayout From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243115
2015-07-25 00:04:29 +08:00
return Context.toCharUnitsFromBits(
getDataLayout().getTypeStoreSizeInBits(Ty));
Introduce CodeGenModule::GetTargetTypeStoreSize() to calculate the store size of LLVM types in character units. llvm-svn: 94542
2010-01-26 21:48:07 +08:00
}
Convert clang::LangAS to a strongly typed enum 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
2017-10-16 02:48:14 +08:00
LangAS CodeGenModule::GetGlobalVarAddressSpace(const VarDecl *D) {
LangAS AddrSpace = LangAS::Default;
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
if (LangOpts.OpenCL) {
Convert clang::LangAS to a strongly typed enum 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
2017-10-16 02:48:14 +08:00
AddrSpace = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
assert(AddrSpace == LangAS::opencl_global ||
AddrSpace == LangAS::opencl_constant ||
AddrSpace == LangAS::opencl_local ||
AddrSpace >= LangAS::FirstTargetAddressSpace);
return AddrSpace;
}
if (LangOpts.CUDA && LangOpts.CUDAIsDevice) {
if (D && D->hasAttr<CUDAConstantAttr>())
return LangAS::cuda_constant;
else if (D && D->hasAttr<CUDASharedAttr>())
return LangAS::cuda_shared;
CUDA: add CodeGen support for global variable address spaces. Because in CUDA types do not have associated address spaces, globals are declared in their "native" address space, and accessed by bitcasting the pointer to address space 0. This relies on address space 0 being a unified address space. llvm-svn: 157167
2012-05-21 05:08:35 +08:00
else
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
return LangAS::cuda_device;
CUDA: add CodeGen support for global variable address spaces. Because in CUDA types do not have associated address spaces, globals are declared in their "native" address space, and accessed by bitcasting the pointer to address space 0. This relies on address space 0 being a unified address space. llvm-svn: 157167
2012-05-21 05:08:35 +08:00
}
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
return getTargetCodeGenInfo().getGlobalVarAddressSpace(*this, D);
CUDA: add CodeGen support for global variable address spaces. Because in CUDA types do not have associated address spaces, globals are declared in their "native" address space, and accessed by bitcasting the pointer to address space 0. This relies on address space 0 being a unified address space. llvm-svn: 157167
2012-05-21 05:08:35 +08:00
}
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
template<typename SomeDecl>
void CodeGenModule::MaybeHandleStaticInExternC(const SomeDecl *D,
llvm::GlobalValue *GV) {
if (!getLangOpts().CPlusPlus)
return;
// Must have 'used' attribute, or else inline assembly can't rely on
// the name existing.
if (!D->template hasAttr<UsedAttr>())
return;
// Must have internal linkage and an ordinary name.
Cleanup handling of UniqueExternalLinkage. This patch renames getLinkage to getLinkageInternal. Only code that needs to handle UniqueExternalLinkage specially should call this. Linkage, as defined in the c++ standard, is provided by getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage. Most places in the compiler actually want isExternallyVisible, which handles UniqueExternalLinkage as internal. llvm-svn: 181677
2013-05-13 08:12:11 +08:00
if (!D->getIdentifier() || D->getFormalLinkage() != InternalLinkage)
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
return;
// Must be in an extern "C" context. Entities declared directly within
// a record are not extern "C" even if the record is in such a context.
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
const SomeDecl *First = D->getFirstDecl();
Make all 'is in extern "C"' tests use the lexical context. I was not able to find a case (other than the fix in r181163) where this makes a difference, but it is a more obviously correct API to have. llvm-svn: 181165
2013-05-06 04:15:21 +08:00
if (First->getDeclContext()->isRecord() || !First->isInExternCContext())
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
return;
// OK, this is an internal linkage entity inside an extern "C" linkage
// specification. Make a note of that so we can give it the "expected"
// mangled name if nothing else is using that name.
Remove nondeterminism introduced in r178950. llvm-svn: 178952
2013-04-06 15:07:44 +08:00
std::pair<StaticExternCMap::iterator, bool> R =
StaticExternCValues.insert(std::make_pair(D->getIdentifier(), GV));
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
// If we have multiple internal linkage entities with the same name
// in extern "C" regions, none of them gets that name.
Remove nondeterminism introduced in r178950. llvm-svn: 178952
2013-04-06 15:07:44 +08:00
if (!R.second)
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
R.first->second = nullptr;
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
}
[patch][pr19848] Produce explicit comdats in clang. The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
2015-01-13 06:13:53 +08:00
static bool shouldBeInCOMDAT(CodeGenModule &CGM, const Decl &D) {
if (!CGM.supportsCOMDAT())
return false;
if (D.hasAttr<SelectAnyAttr>())
return true;
GVALinkage Linkage;
if (auto *VD = dyn_cast<VarDecl>(&D))
Linkage = CGM.getContext().GetGVALinkageForVariable(VD);
else
Linkage = CGM.getContext().GetGVALinkageForFunction(cast<FunctionDecl>(&D));
switch (Linkage) {
case GVA_Internal:
case GVA_AvailableExternally:
case GVA_StrongExternal:
return false;
case GVA_DiscardableODR:
case GVA_StrongODR:
return true;
}
llvm_unreachable("No such linkage");
}
Use a trivial comdat for inline ctor/dtor when not using C5/D5. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226211
2015-01-16 05:36:08 +08:00
void CodeGenModule::maybeSetTrivialComdat(const Decl &D,
llvm::GlobalObject &GO) {
if (!shouldBeInCOMDAT(*this, D))
return;
GO.setComdat(TheModule.getOrInsertComdat(GO.getName()));
}
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
/// Pass IsTentative as true if you want to create a tentative definition.
void CodeGenModule::EmitGlobalVarDefinition(const VarDecl *D,
bool IsTentative) {
[OpenCL] Generate opaque type for sampler_t and function call for the initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
2016-07-29 03:26:30 +08:00
// OpenCL global variables of sampler type are translated to function calls,
// therefore no need to be translated.
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
QualType ASTTy = D->getType();
[OpenCL] Generate opaque type for sampler_t and function call for the initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
2016-07-29 03:26:30 +08:00
if (getLangOpts().OpenCL && ASTTy->isSamplerT())
return;
llvm::Constant *Init = nullptr;
Deal with a horrible C++11 special case. If a non-literal type has a constexpr constructor, and that constructor is used to initialize an object of static storage duration such that all members and bases are initialized by constant expressions, constant initialization is performed. In this case, the object can still have a non-trivial destructor, and if it does, we must emit a dynamic initializer which performs no initialization and instead simply registers that destructor. llvm-svn: 150419
2012-02-14 06:16:19 +08:00
CXXRecordDecl *RD = ASTTy->getBaseElementTypeUnsafe()->getAsCXXRecordDecl();
bool NeedsGlobalCtor = false;
bool NeedsGlobalDtor = RD && !RD->hasTrivialDestructor();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
constexpr irgen: Add irgen support for APValue::Struct, APValue::Union, APValue::Array and APValue::MemberPointer. All APValue values can now be emitted as constants. Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other entrypoints dealing with constant member pointers are no longer necessary and will be removed in a later change. Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to VarDecl::evaluateValue. This performs caching and deals with the nasty cases in C++11 where a non-const object's initializer can refer indirectly to previously-initialized fields within the same object. Building the intermediate APValue object incurs a measurable performance hit on pathological testcases with huge initializer lists, so we continue to build IR directly from the Expr nodes for array and record types outside of C++11. llvm-svn: 148178
2012-01-14 12:30:29 +08:00
const VarDecl *InitDecl;
const Expr *InitExpr = D->getAnyInitializer(InitDecl);
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
Optional<ConstantEmitter> emitter;
[CUDA] Do not allow dynamic initialization of global device side variables. In general CUDA does not allow dynamic initialization of global device-side variables. One exception is that CUDA allows records with empty constructors as described in section E2.2.1 of CUDA 7.5 Programming guide. This patch applies initializer checks for all device-side variables. Empty constructors are accepted, but no code is generated for them. Differential Revision: http://reviews.llvm.org/D15305 llvm-svn: 259592
2016-02-03 06:29:48 +08:00
// CUDA E.2.4.1 "__shared__ variables cannot have an initialization
// as part of their declaration." Sema has already checked for
// error cases, so we just need to set Init to UndefValue.
if (getLangOpts().CUDA && getLangOpts().CUDAIsDevice &&
D->hasAttr<CUDASharedAttr>())
[CUDA] Change initializer for CUDA device code based on CUDA documentation. Summary: According to CUDA documentation, global variables declared with __device__, __constant__ can be initialized from host code, so mark them as externally initialized. Because __shared__ variables cannot have an initialization as part of their declaration and since the value maybe kept across different kernel invocation, the value of __shared__ is effectively undefined instead of zero initialized. Wrongly using zero initializer may cause illegitimate optimization, e.g. removing unused __constant__ variable because it's not updated in the device code and the value is initialized with zero. Test Plan: test/CodeGenCUDA/address-spaces.cu Patch by Xuetian Weng Reviewers: jholewinski, eliben, tra, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12241 llvm-svn: 245786
2015-08-22 13:49:28 +08:00
Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
[CUDA] Do not allow dynamic initialization of global device side variables. In general CUDA does not allow dynamic initialization of global device-side variables. One exception is that CUDA allows records with empty constructors as described in section E2.2.1 of CUDA 7.5 Programming guide. This patch applies initializer checks for all device-side variables. Empty constructors are accepted, but no code is generated for them. Differential Revision: http://reviews.llvm.org/D15305 llvm-svn: 259592
2016-02-03 06:29:48 +08:00
else if (!InitExpr) {
PR1893: Fix up the type of tentative definitions of incomplete array types so that they end up the correct size. llvm-svn: 51787
2008-05-31 04:39:54 +08:00
// This is a tentative definition; tentative definitions are
Defer generation of tentative definitions. - PR3980. - <rdar://problem/6762287> [irgen] crash when generating tentative definition of incomplete structure - This also avoids creating common definitions for things which are later overwritten. - XFAIL'ed external-defs.c, it isn't completing types properly yet. llvm-svn: 69231
2009-04-16 06:08:45 +08:00
// implicitly initialized with { 0 }.
//
// Note that tentative definitions are only emitted at the end of
// a translation unit, so they should never have incomplete
// type. In addition, EmitTentativeDefinition makes sure that we
// never attempt to emit a tentative definition if a real one
// exists. A use may still exists, however, so we still may need
// to do a RAUW.
assert(!ASTTy->isIncompleteType() && "Unexpected incomplete type");
use CodeGenModule::EmitNullConstant in a couple of places. llvm-svn: 77915
2009-08-03 05:18:22 +08:00
Init = EmitNullConstant(D->getType());
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
} else {
PR12086, PR15117 Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
2013-06-13 06:31:48 +08:00
initializedGlobalDecl = GlobalDecl(D);
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
emitter.emplace(*this);
Init = emitter->tryEmitForInitializer(*InitDecl);
CodeGen support for global variables of type std::initializer_list<X>. This emits a backing array with internal linkage and fills it with data, then has the initializer_list point at the array. Dynamic initialization and global destructors are correctly supported. What doesn't work is nested initializer_lists. I have no idea how to get them to work, either. However, these should be very rare, and so I'll just call it a known bug and declare generalized initializers DONE! llvm-svn: 151457
2012-02-26 04:51:20 +08:00
Initialize the Init variable to something reasonable when we emit an error, so we don't crash. llvm-svn: 65099
2009-02-20 09:18:21 +08:00
if (!Init) {
Use the right definition when emitting a global variable. Fixes PR5564. llvm-svn: 94555
2010-01-27 01:43:42 +08:00
QualType T = InitExpr->getType();
When we emit a non-constant initializer for a global variable of reference type, make sure that the initializer we build is the of the appropriate type for the *reference*, not for the thing that it refers to. Fixes PR7050. llvm-svn: 103115
2010-05-06 04:15:55 +08:00
if (D->getType()->isReferenceType())
T = D->getType();
constexpr irgen: Add irgen support for APValue::Struct, APValue::Union, APValue::Array and APValue::MemberPointer. All APValue values can now be emitted as constants. Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other entrypoints dealing with constant member pointers are no longer necessary and will be removed in a later change. Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to VarDecl::evaluateValue. This performs caching and deals with the nasty cases in C++11 where a non-const object's initializer can refer indirectly to previously-initialized fields within the same object. Building the intermediate APValue object incurs a measurable performance hit on pathological testcases with huge initializer lists, so we continue to build IR directly from the Expr nodes for array and record types outside of C++11. llvm-svn: 148178
2012-01-14 12:30:29 +08:00
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().CPlusPlus) {
Add support for global initializers. llvm-svn: 78515
2009-08-09 07:24:23 +08:00
Init = EmitNullConstant(T);
Deal with a horrible C++11 special case. If a non-literal type has a constexpr constructor, and that constructor is used to initialize an object of static storage duration such that all members and bases are initialized by constant expressions, constant initialization is performed. In this case, the object can still have a non-trivial destructor, and if it does, we must emit a dynamic initializer which performs no initialization and instead simply registers that destructor. llvm-svn: 150419
2012-02-14 06:16:19 +08:00
NeedsGlobalCtor = true;
Add support for global initializers. llvm-svn: 78515
2009-08-09 07:24:23 +08:00
} else {
ErrorUnsupported(D, "static initializer");
Init = llvm::UndefValue::get(getTypes().ConvertType(T));
}
When deferring the emission of declarations with initializers in C++, remember the order they appeared in the translation unit. If they get emitted, put them in their proper order. Fixes rdar://problem/7458115 llvm-svn: 108477
2010-07-16 07:40:35 +08:00
} else {
// We don't need an initializer, so remove the entry for the delayed
Deal with a horrible C++11 special case. If a non-literal type has a constexpr constructor, and that constructor is used to initialize an object of static storage duration such that all members and bases are initialized by constant expressions, constant initialization is performed. In this case, the object can still have a non-trivial destructor, and if it does, we must emit a dynamic initializer which performs no initialization and instead simply registers that destructor. llvm-svn: 150419
2012-02-14 06:16:19 +08:00
// initializer position (just in case this entry was delayed) if we
// also don't need to register a destructor.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().CPlusPlus && !NeedsGlobalDtor)
When deferring the emission of declarations with initializers in C++, remember the order they appeared in the translation unit. If they get emitted, put them in their proper order. Fixes rdar://problem/7458115 llvm-svn: 108477
2010-07-16 07:40:35 +08:00
DelayedCXXInitPosition.erase(D);
Initialize the Init variable to something reasonable when we emit an error, so we don't crash. llvm-svn: 65099
2009-02-20 09:18:21 +08:00
}
Implement trivial integer initializers, like 'int X = 4;' for global vars. Approach suggested by Keith. llvm-svn: 39849
2007-07-14 08:23:28 +08:00
}
Codegen global array initializers. llvm-svn: 43383
2007-10-27 00:31:40 +08:00
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type* InitType = Init->getType();
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
llvm::Constant *Entry =
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
GetAddrOfGlobalVar(D, InitType, ForDefinition_t(!IsTentative));
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
// Strip off a bitcast if we got one back.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *CE = dyn_cast<llvm::ConstantExpr>(Entry)) {
use CreateRuntimeVariable to get __CFConstantStringClassReference instead of doing it manually (which might end up getting auto-renamed), fixing a FIXME. rdar://7065446 llvm-svn: 76079
2009-07-17 00:48:25 +08:00
assert(CE->getOpcode() == llvm::Instruction::BitCast ||
Fix test failures after addrspacecast added. Bitcasts between address spaces are no longer allowed. llvm-svn: 194765
2013-11-15 10:19:52 +08:00
CE->getOpcode() == llvm::Instruction::AddrSpaceCast ||
// All zero index gep.
use CreateRuntimeVariable to get __CFConstantStringClassReference instead of doing it manually (which might end up getting auto-renamed), fixing a FIXME. rdar://7065446 llvm-svn: 76079
2009-07-17 00:48:25 +08:00
CE->getOpcode() == llvm::Instruction::GetElementPtr);
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
Entry = CE->getOperand(0);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
// Entry is now either a Function or GlobalVariable.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = dyn_cast<llvm::GlobalVariable>(Entry);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
// We have a definition after a declaration with the wrong type.
// We must make a new GlobalVariable* and update everything that used OldGV
// (a declaration or tentative definition) with the new GlobalVariable*
// (which will be a definition).
//
// This happens if there is a prototype for a global (e.g.
// "extern int x[];") and then a definition of a different type (e.g.
// "int x[10];"). This also happens when an initializer has a different type
// from the type of the global (this happens with unions).
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
if (!GV || GV->getType()->getElementType() != InitType ||
Add support for language-specific address spaces. On top of that, add support for the OpenCL __private, __local, __constant and __global address spaces, as well as the __read_only, _read_write and __write_only image access specifiers. Patch originally by ARM; language-specific address space support by myself. llvm-svn: 127915
2011-03-19 06:38:29 +08:00
GV->getType()->getAddressSpace() !=
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
getContext().getTargetAddressSpace(GetGlobalVarAddressSpace(D))) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
// Move the old entry aside so that we'll create a new one.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
Entry->setName(StringRef());
Emission of global variable initialializer was broken in rare situation where a tentative decl was emitted *after* the actual initialization. This occurs in some rare situations with static decls. - PR3613. - I'm not particularly happy with this fix, but I don't see a simpler or more elegant solution yet. llvm-svn: 65018
2009-02-19 13:36:41 +08:00
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
// Make a new global with the correct type, this is now guaranteed to work.
PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a declaration and a definition using the same name but different types, we emit what is in the definition. When there are two conflicting definitions, we issue an error. Differential Revision: http://reviews.llvm.org/D15686 llvm-svn: 257754
2016-01-14 18:41:16 +08:00
GV = cast<llvm::GlobalVariable>(
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
GetAddrOfGlobalVar(D, InitType, ForDefinition_t(!IsTentative)));
fix a crash that could occur when a variable declaration became a function definition. llvm-svn: 67446
2009-03-21 17:25:43 +08:00
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
// Replace all uses of the old global with the new global
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
llvm::Constant *NewPtrForOldDecl =
Update for LLVM API change. llvm-svn: 77492
2009-07-30 02:54:39 +08:00
llvm::ConstantExpr::getBitCast(GV, Entry->getType());
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
Entry->replaceAllUsesWith(NewPtrForOldDecl);
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
// Erase the old global, since it is no longer used.
simplify and cleanup global variable creation stuff to all go through one code path. llvm-svn: 67445
2009-03-21 17:16:30 +08:00
cast<llvm::GlobalValue>(Entry)->eraseFromParent();
Allow the type of a global to be different from the type of its associated declaration. This is a prerequisite to handling general union initializations; for example, an array of unions involving pointers has to be turned into a struct because the elements can have incompatible types. I refactored the code a bit to make it more readable; now, the logic for definitions is all in EmitGlobalVarInit. The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it separately. By itself, this patch should not cause any visible changes. llvm-svn: 51783
2008-05-31 03:50:47 +08:00
}
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
MaybeHandleStaticInExternC(D, GV);
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
if (D->hasAttr<AnnotateAttr>())
AddGlobalAnnotations(D, GV);
Generate code for annotation attributes. llvm-svn: 49951
2008-04-19 12:17:09 +08:00
[CUDA] Emit host-side 'shadows' for device-side global variables ... and register them with CUDA runtime. This is needed for commonly used cudaMemcpy*() APIs that use address of host-side shadow to access their counterparts on device side. Fixes PR26340 Differential Revision: http://reviews.llvm.org/D17779 llvm-svn: 262498
2016-03-03 02:28:50 +08:00
// Set the llvm linkage type as appropriate.
llvm::GlobalValue::LinkageTypes Linkage =
getLLVMLinkageVarDefinition(D, GV->isConstant());
[CUDA] Change initializer for CUDA device code based on CUDA documentation. Summary: According to CUDA documentation, global variables declared with __device__, __constant__ can be initialized from host code, so mark them as externally initialized. Because __shared__ variables cannot have an initialization as part of their declaration and since the value maybe kept across different kernel invocation, the value of __shared__ is effectively undefined instead of zero initialized. Wrongly using zero initializer may cause illegitimate optimization, e.g. removing unused __constant__ variable because it's not updated in the device code and the value is initialized with zero. Test Plan: test/CodeGenCUDA/address-spaces.cu Patch by Xuetian Weng Reviewers: jholewinski, eliben, tra, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12241 llvm-svn: 245786
2015-08-22 13:49:28 +08:00
// CUDA B.2.1 "The __device__ qualifier declares a variable that resides on
// the device. [...]"
// CUDA B.2.2 "The __constant__ qualifier, optionally used together with
// __device__, declares a variable that: [...]
// Is accessible from all the threads within the grid and from the host
// through the runtime library (cudaGetSymbolAddress() / cudaGetSymbolSize()
// / cudaMemcpyToSymbol() / cudaMemcpyFromSymbol())."
[CUDA] Emit host-side 'shadows' for device-side global variables ... and register them with CUDA runtime. This is needed for commonly used cudaMemcpy*() APIs that use address of host-side shadow to access their counterparts on device side. Fixes PR26340 Differential Revision: http://reviews.llvm.org/D17779 llvm-svn: 262498
2016-03-03 02:28:50 +08:00
if (GV && LangOpts.CUDA) {
if (LangOpts.CUDAIsDevice) {
if (D->hasAttr<CUDADeviceAttr>() || D->hasAttr<CUDAConstantAttr>())
GV->setExternallyInitialized(true);
} else {
// Host-side shadows of external declarations of device-side
// global variables become internal definitions. These have to
// be internal in order to prevent name conflicts with global
// host variables with the same name in a different TUs.
if (D->hasAttr<CUDADeviceAttr>() || D->hasAttr<CUDAConstantAttr>()) {
Linkage = llvm::GlobalValue::InternalLinkage;
// Shadow variables and their properties must be registered
// with CUDA runtime.
unsigned Flags = 0;
if (!D->hasDefinition())
Flags |= CGCUDARuntime::ExternDeviceVar;
if (D->hasAttr<CUDAConstantAttr>())
Flags |= CGCUDARuntime::ConstantDeviceVar;
getCUDARuntime().registerDeviceVar(*GV, Flags);
} else if (D->hasAttr<CUDASharedAttr>())
// __shared__ variables are odd. Shadows do get created, but
// they are not registered with the CUDA runtime, so they
// can't really be used to access their device-side
// counterparts. It's not clear yet whether it's nvcc's bug or
// a feature, but we've got to do the same for compatibility.
Linkage = llvm::GlobalValue::InternalLinkage;
}
[CUDA] Change initializer for CUDA device code based on CUDA documentation. Summary: According to CUDA documentation, global variables declared with __device__, __constant__ can be initialized from host code, so mark them as externally initialized. Because __shared__ variables cannot have an initialization as part of their declaration and since the value maybe kept across different kernel invocation, the value of __shared__ is effectively undefined instead of zero initialized. Wrongly using zero initializer may cause illegitimate optimization, e.g. removing unused __constant__ variable because it's not updated in the device code and the value is initialized with zero. Test Plan: test/CodeGenCUDA/address-spaces.cu Patch by Xuetian Weng Reviewers: jholewinski, eliben, tra, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12241 llvm-svn: 245786
2015-08-22 13:49:28 +08:00
}
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
implement support for basic codegen of global variables with no initializers. llvm-svn: 39795
2007-07-13 13:13:43 +08:00
GV->setInitializer(Init);
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
if (emitter) emitter->finalize(GV);
weak globals that are const should get weak_odr linkage. add a fixme about C++ const. llvm-svn: 78159
2009-08-05 13:20:29 +08:00
// If it is safe to mark the global 'constant', do so now.
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
GV->setConstant(!NeedsGlobalCtor && !NeedsGlobalDtor &&
isTypeConstant(D->getType(), true));
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
MS Compat: mark globals emitted in read-only sections const They cannot be written to, so marking them const makes sense and may improve optimisation. As a side-effect, SectionInfos has to be moved from Sema to ASTContext. It also fixes this problem, that occurs when compiling ATL: warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes The ATL headers are putting variables in a special section that's marked read-only. However, Clang currently can't model that read-onlyness in the IR. But, by making the variables const, the section does become read-only, and the linker warning is avoided. Differential Revision: http://reviews.llvm.org/D5812 llvm-svn: 219960
2014-10-17 04:52:46 +08:00
// If it is in a read-only section, mark it 'constant'.
if (const SectionAttr *SA = D->getAttr<SectionAttr>()) {
const ASTContext::SectionInfo &SI = Context.SectionInfos[SA->getName()];
if ((SI.SectionFlags & ASTContext::PSF_Write) == 0)
GV->setConstant(true);
}
Change the return type of ASTContext::getDeclAlignInBytes() to CharUnits and, now that the "InBytes" part of the name is implied by the return type, rename it to getDeclAlign(). llvm-svn: 94681
2010-01-28 01:10:57 +08:00
GV->setAlignment(getContext().getDeclAlign(D).getQuantity());
Bug fix: do not emit static const local variables with mutable members as constants. Refactor and simplify all the separate checks for whether a type can be emitted as a constant. llvm-svn: 150793
2012-02-17 14:48:11 +08:00
CodeGen: Correct linkage of thread_local for OS X The backing store of thread local variables is internal for OS X and all accesses must go through the thread wrapper. However, individual TUs may have inlined through the thread wrapper. To fix this, give the thread wrapper functions WeakAnyLinkage. This prevents them from getting inlined into call-sites. This fixes PR19989. llvm-svn: 210632
2014-06-11 12:08:55 +08:00
[TLS on Darwin] change how we handle globals with linkonce or weak linkage. This is about how we handle static member of a template. Before this commit, we use internal linkage for the IR thread-local variable, which is inefficient. With this commit, we will start to follow Itanium C++ ABI. rdar://problem/23415206 Reviewed by John McCall. llvm-svn: 252814
2015-11-12 06:42:31 +08:00
// On Darwin, if the normal linkage of a C++ thread_local variable is
// LinkOnce or Weak, we keep the normal linkage to prevent multiple
// copies within a linkage unit; otherwise, the backing variable has
// internal linkage and all accesses should just be calls to the
CodeGen: Correct linkage of thread_local for OS X The backing store of thread local variables is internal for OS X and all accesses must go through the thread wrapper. However, individual TUs may have inlined through the thread wrapper. To fix this, give the thread wrapper functions WeakAnyLinkage. This prevents them from getting inlined into call-sites. This fixes PR19989. llvm-svn: 210632
2014-06-11 12:08:55 +08:00
// Itanium-specified entry point, which has the normal linkage of the
[TLS on Darwin] change how we handle globals with linkonce or weak linkage. This is about how we handle static member of a template. Before this commit, we use internal linkage for the IR thread-local variable, which is inefficient. With this commit, we will start to follow Itanium C++ ABI. rdar://problem/23415206 Reviewed by John McCall. llvm-svn: 252814
2015-11-12 06:42:31 +08:00
// variable. This is to preserve the ability to change the implementation
// behind the scenes.
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
if (!D->isStaticLocal() && D->getTLSKind() == VarDecl::TLS_Dynamic &&
[TLS on Darwin] treat all Darwin platforms in the same way. rdar://problem/9001553 llvm-svn: 252820
2015-11-12 07:08:18 +08:00
Context.getTargetInfo().getTriple().isOSDarwin() &&
[TLS on Darwin] change how we handle globals with linkonce or weak linkage. This is about how we handle static member of a template. Before this commit, we use internal linkage for the IR thread-local variable, which is inefficient. With this commit, we will start to follow Itanium C++ ABI. rdar://problem/23415206 Reviewed by John McCall. llvm-svn: 252814
2015-11-12 06:42:31 +08:00
!llvm::GlobalVariable::isLinkOnceLinkage(Linkage) &&
!llvm::GlobalVariable::isWeakLinkage(Linkage))
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
Linkage = llvm::GlobalValue::InternalLinkage;
CodeGen: Correct linkage of thread_local for OS X The backing store of thread local variables is internal for OS X and all accesses must go through the thread wrapper. However, individual TUs may have inlined through the thread wrapper. To fix this, give the thread wrapper functions WeakAnyLinkage. This prevents them from getting inlined into call-sites. This fixes PR19989. llvm-svn: 210632
2014-06-11 12:08:55 +08:00
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
GV->setLinkage(Linkage);
Update CodeGen to use DLL storage class for dllimport/dllexport With the old linkage types removed, set the linkage to external for both dllimport and dllexport to reflect what's currently supported. llvm-svn: 199220
2014-01-14 23:23:53 +08:00
if (D->hasAttr<DLLImportAttr>())
GV->setDLLStorageClass(llvm::GlobalVariable::DLLImportStorageClass);
else if (D->hasAttr<DLLExportAttr>())
GV->setDLLStorageClass(llvm::GlobalVariable::DLLExportStorageClass);
Don't dllimport inline functions when targeting MinGW (PR21366) It turns out that MinGW never dllimports of exports inline functions. This means that code compiled with Clang would fail to link with MinGW-compiled libraries since we might try to import functions that are not imported. To fix this, make Clang never dllimport inline functions when targeting MinGW. llvm-svn: 221154
2014-11-03 22:24:45 +08:00
else
GV->setDLLStorageClass(llvm::GlobalVariable::DefaultStorageClass);
[-cxx-abi microsoft] Emit linkonce_odr definitions for declarations of static data members with inline initializers (PR17689) This makes Clang emit a linkonce_odr definition for 'val' in the code below, to be compatible with MSVC-compiled code: struct Foo { static const int val = 1; }; Differential Revision: http://llvm-reviews.chandlerc.com/D2233 llvm-svn: 195283
2013-11-21 08:15:56 +08:00
Re-commit r289252 and r289285, and fix PR31374 llvm-svn: 289787
2016-12-15 16:09:08 +08:00
if (Linkage == llvm::GlobalVariable::CommonLinkage) {
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
// common vars aren't constant even if declared const.
GV->setConstant(false);
Re-commit r289252 and r289285, and fix PR31374 llvm-svn: 289787
2016-12-15 16:09:08 +08:00
// Tentative definition of global variables may be initialized with
// non-zero null pointers. In this case they should have weak linkage
// since common linkage must have zero initializer and must not have
// explicit section therefore cannot have non-zero initial value.
if (!GV->getInitializer()->isNullValue())
GV->setLinkage(llvm::GlobalVariable::WeakAnyLinkage);
}
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
Fix pr19653. Warn if an alias requests a section other than the aliasee section. llvm-svn: 207997
2014-05-06 04:21:03 +08:00
setNonAliasAttributes(D, GV);
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
if (D->getTLSKind() && !GV->isThreadLocal()) {
if (D->getTLSKind() == VarDecl::TLS_Dynamic)
Fix use-after-free when a C++ thread_local variable gets replaced (because its type changes when the initializer is attached). Don't hold onto the GlobalVariable*; recompute it from the VarDecl* instead. llvm-svn: 254359
2015-12-01 09:10:48 +08:00
CXXThreadLocals.push_back(D);
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
setTLSMode(GV, *D);
}
Use a trivial comdat for inline ctor/dtor when not using C5/D5. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226211
2015-01-16 05:36:08 +08:00
maybeSetTrivialComdat(*D, *GV);
[patch][pr19848] Produce explicit comdats in clang. The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
2015-01-13 06:13:53 +08:00
Simplify the logic for emitting guard variables for template static data members by delaying the emission of the initializer until after linkage and visibility have been set on the global. Also, don't emit a guard unless the variable actually ends up with vague linkage, and don't use thread-safe statics in any case. llvm-svn: 118336
2010-11-06 17:44:32 +08:00
// Emit the initializer function if necessary.
Deal with a horrible C++11 special case. If a non-literal type has a constexpr constructor, and that constructor is used to initialize an object of static storage duration such that all members and bases are initialized by constant expressions, constant initialization is performed. In this case, the object can still have a non-trivial destructor, and if it does, we must emit a dynamic initializer which performs no initialization and instead simply registers that destructor. llvm-svn: 150419
2012-02-14 06:16:19 +08:00
if (NeedsGlobalCtor || NeedsGlobalDtor)
EmitCXXGlobalVarDeclInitFunc(D, GV, NeedsGlobalCtor);
Simplify the logic for emitting guard variables for template static data members by delaying the emission of the initializer until after linkage and visibility have been set on the global. Also, don't emit a guard unless the variable actually ends up with vague linkage, and don't use thread-safe statics in any case. llvm-svn: 118336
2010-11-06 17:44:32 +08:00
[Sanitizer] Introduce SanitizerMetadata class. It is responsible for generating metadata consumed by sanitizer instrumentation passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata. For now the class is stateless, but soon it won't be the case. Instead of creating globals providing source-level information to ASan, we will create metadata nodes/strings which will be turned into actual global variables in the backend (if needed). No functionality change. llvm-svn: 214564
2014-08-02 05:35:28 +08:00
SanitizerMD->reportGlobalToASan(GV, *D, NeedsGlobalCtor);
[asan] If we are compiling with ASan, add metadata indicating dynamically initialized globals. Patch by Reid Watson, reviewed by Richard Smith llvm-svn: 162259
2012-08-21 14:53:28 +08:00
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
// Emit global variable debug information.
Recommit: Start handling debug line and scope information better: Migrate most of the location setting within the larger API in CGDebugInfo and update a lot of callers. Remove the existing file/scope change machinery in UpdateLineDirectiveRegion and replace it with DILexicalBlockFile usage. Finishes off the rest of rdar://10246360 after fixing a few bugs that were exposed in gdb testsuite testing. llvm-svn: 141893
2011-10-14 05:45:18 +08:00
if (CGDebugInfo *DI = getModuleDebugInfo())
Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend. llvm-svn: 259489
2016-02-02 19:06:51 +08:00
if (getCodeGenOpts().getDebugInfo() >= codegenoptions::LimitedDebugInfo)
This patch adds a new Clang compiler flag "-gline-tables-only". It reduces the amount of emitted debug information: 1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram, DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only. 2) .debug_str contains only function names. 3) No debug data for types/namespaces/variables is emitted. 4) The data in .debug_line is enough to produce valid stack traces with function names and line numbers. Reviewed by Eric Christopher. llvm-svn: 156160
2012-05-04 15:39:27 +08:00
DI->EmitGlobalVariable(GV, D);
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
}
MS ABI: Aligned tentative definitions don't have CommonLinkage int __declspec(align(16)) foo; is a tentative definition but the storage for that variable should not have CommonLinkage. llvm-svn: 214828
2014-08-05 08:01:13 +08:00
static bool isVarDeclStrongDefinition(const ASTContext &Context,
Don't crash when a selectany symbol would get common linkage Things can't both be in comdats and have common linkage, so never give things in comdats common linkage. Common linkage is only used in .c files, and the only thing that can trigger a comdat in c is selectany from what I can tell. Fixes PR23243. Also address an over-the-shoulder review comment from rnk by moving the hasAttr<SelectAnyAttr>() in Decl.cpp around a bit. It only makes a minor difference for selectany on global variables, so it goes well with the rest of this patch. http://reviews.llvm.org/D9042 llvm-svn: 235053
2015-04-16 07:04:24 +08:00
CodeGenModule &CGM, const VarDecl *D,
bool NoCommon) {
CodeGen: Clean up CommonLinkage calculation No functionality change. llvm-svn: 205972
2014-04-11 00:53:16 +08:00
// Don't give variables common linkage if -fno-common was specified unless it
// was overridden by a NoCommon attribute.
if ((NoCommon || D->hasAttr<NoCommonAttr>()) && !D->hasAttr<CommonAttr>())
return true;
// C11 6.9.2/2:
// A declaration of an identifier for an object that has file scope without
// an initializer, and without a storage-class specifier or with the
// storage-class specifier static, constitutes a tentative definition.
if (D->getInit() || D->hasExternalStorage())
return true;
// A variable cannot be both common and exist in a section.
if (D->hasAttr<SectionAttr>())
return true;
Add support for #pragma clang section This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
2017-06-05 18:11:57 +08:00
// A variable cannot be both common and exist in a section.
// We dont try to determine which is the right section in the front-end.
// If no specialized section name is applicable, it will resort to default.
if (D->hasAttr<PragmaClangBSSSectionAttr>() ||
D->hasAttr<PragmaClangDataSectionAttr>() ||
D->hasAttr<PragmaClangRodataSectionAttr>())
return true;
CodeGen: Clean up CommonLinkage calculation No functionality change. llvm-svn: 205972
2014-04-11 00:53:16 +08:00
// Thread local vars aren't considered common linkage.
if (D->getTLSKind())
return true;
// Tentative definitions marked with WeakImportAttr are true definitions.
if (D->hasAttr<WeakImportAttr>())
return true;
Don't crash when a selectany symbol would get common linkage Things can't both be in comdats and have common linkage, so never give things in comdats common linkage. Common linkage is only used in .c files, and the only thing that can trigger a comdat in c is selectany from what I can tell. Fixes PR23243. Also address an over-the-shoulder review comment from rnk by moving the hasAttr<SelectAnyAttr>() in Decl.cpp around a bit. It only makes a minor difference for selectany on global variables, so it goes well with the rest of this patch. http://reviews.llvm.org/D9042 llvm-svn: 235053
2015-04-16 07:04:24 +08:00
// A variable cannot be both common and exist in a comdat.
if (shouldBeInCOMDAT(CGM, *D))
return true;
fix typo; NFC llvm-svn: 274278
2016-07-01 05:02:40 +08:00
// Declarations with a required alignment do not have common linkage in MSVC
MS ABI: Aligned tentative definitions don't have CommonLinkage int __declspec(align(16)) foo; is a tentative definition but the storage for that variable should not have CommonLinkage. llvm-svn: 214828
2014-08-05 08:01:13 +08:00
// mode.
[MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility No ABI for C++ currently makes it possible to implement the standard 100% perfectly. We wrongly hid some of our compatible behavior behind -fms-compatibility instead of tying it to the compiler ABI. llvm-svn: 249656
2015-10-08 12:53:31 +08:00
if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
MS ABI: Records with fields with required aligmnet shouldn't be common llvm-svn: 227954
2015-02-03 16:49:32 +08:00
if (D->hasAttr<AlignedAttr>())
return true;
QualType VarType = D->getType();
if (Context.isAlignmentRequired(VarType))
return true;
if (const auto *RT = VarType->getAs<RecordType>()) {
const RecordDecl *RD = RT->getDecl();
for (const FieldDecl *FD : RD->fields()) {
if (FD->isBitField())
continue;
if (FD->hasAttr<AlignedAttr>())
return true;
if (Context.isAlignmentRequired(FD->getType()))
return true;
}
}
}
MS ABI: Aligned tentative definitions don't have CommonLinkage int __declspec(align(16)) foo; is a tentative definition but the storage for that variable should not have CommonLinkage. llvm-svn: 214828
2014-08-05 08:01:13 +08:00
CodeGen: Clean up CommonLinkage calculation No functionality change. llvm-svn: 205972
2014-04-11 00:53:16 +08:00
return false;
}
Rename CodeGenModule::getLLVMLinkageforDeclarator -> getLLVMLinkageForDeclarator No functionality change. llvm-svn: 208808
2014-05-15 03:54:53 +08:00
llvm::GlobalValue::LinkageTypes CodeGenModule::getLLVMLinkageForDeclarator(
Don't dllimport/export destructor variants implemented by thunks. MSVC doesn't export these functions, so trying to import them doesnt' work. Also, don't let any dll attributes on the CXXDestructorDecl influence the thunk's linkage -- they should always be linkonce_odr. This takes care of the FIXME's for this in Nico's tests. Differential Revision: http://reviews.llvm.org/D3930 llvm-svn: 209706
2014-05-28 09:52:23 +08:00
const DeclaratorDecl *D, GVALinkage Linkage, bool IsConstantVariable) {
Fix a thinko that John pointed out llvm-svn: 84142
2009-10-15 05:36:34 +08:00
if (Linkage == GVA_Internal)
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
return llvm::Function::InternalLinkage;
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
if (D->hasAttr<WeakAttr>()) {
if (IsConstantVariable)
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
return llvm::GlobalVariable::WeakODRLinkage;
weak globals that are const should get weak_odr linkage. add a fixme about C++ const. llvm-svn: 78159
2009-08-05 13:20:29 +08:00
else
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
return llvm::GlobalVariable::WeakAnyLinkage;
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
}
// We are guaranteed to have a strong definition somewhere else,
// so we can use available_externally linkage.
if (Linkage == GVA_AvailableExternally)
Prototype of modules codegen First pass at generating weak definitions of inline functions from module files (& skipping (-O0) or emitting available_externally (optimizations) definitions where those modules are used). External functions defined in modules are emitted into the modular object file as well (this may turn an existing ODR violation (if that module were imported into multiple translations) into valid/linkable code). Internal symbols (static functions, for example) are not correctly supported yet. The symbol will be produced, internal, in the modular object - unreferenceable from the users. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D28845 llvm-svn: 293456
2017-01-30 13:00:26 +08:00
return llvm::GlobalValue::AvailableExternallyLinkage;
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
// Note that Apple's kernel linker doesn't support symbol
// coalescing, so we need to avoid linkonce and weak linkages there.
// Normally, this means we just map to internal, but for explicit
// instantiations we'll map to external.
// In C++, the compiler has to emit a definition in every translation unit
// that references the function. We should use linkonce_odr because
// a) if all references in this translation unit are optimized away, we
// don't need to codegen it. b) if the function persists, it needs to be
// merged with other definitions. c) C++ has the ODR, so we know the
// definition is dependable.
if (Linkage == GVA_DiscardableODR)
Allow dllimport/dllexport on inline functions and adjust the linkage. This is a step towards handling these attributes on classes (PR11170). Differential Revision: http://reviews.llvm.org/D3772 llvm-svn: 208925
2014-05-16 06:07:49 +08:00
return !Context.getLangOpts().AppleKext ? llvm::Function::LinkOnceODRLinkage
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
: llvm::Function::InternalLinkage;
// An explicit instantiation of a template has weak linkage, since
// explicit instantiations can occur in multiple translation units
// and must all be equivalent. However, we are not allowed to
// throw away these explicit instantiations.
[CUDA] Give templated device functions internal linkage, templated kernels external linkage. Summary: This lets LLVM perform IPO over these functions. In particular, it allows LLVM to emit ld.global.nc for loads to __restrict pointers in kernels that are never written to. Reviewers: rsmith Subscribers: cfe-commits, tra Differential Revision: http://reviews.llvm.org/D21337 llvm-svn: 274261
2016-07-01 02:41:33 +08:00
//
// We don't currently support CUDA device code spread out across multiple TUs,
// so say that CUDA templates are either external (for kernels) or internal.
// This lets llvm perform aggressive inter-procedural optimizations.
if (Linkage == GVA_StrongODR) {
if (Context.getLangOpts().AppleKext)
return llvm::Function::ExternalLinkage;
if (Context.getLangOpts().CUDA && Context.getLangOpts().CUDAIsDevice)
return D->hasAttr<CUDAGlobalAttr>() ? llvm::Function::ExternalLinkage
: llvm::Function::InternalLinkage;
return llvm::Function::WeakODRLinkage;
}
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
// C++ doesn't have tentative definitions and thus cannot have common
// linkage.
if (!getLangOpts().CPlusPlus && isa<VarDecl>(D) &&
Don't crash when a selectany symbol would get common linkage Things can't both be in comdats and have common linkage, so never give things in comdats common linkage. Common linkage is only used in .c files, and the only thing that can trigger a comdat in c is selectany from what I can tell. Fixes PR23243. Also address an over-the-shoulder review comment from rnk by moving the hasAttr<SelectAnyAttr>() in Decl.cpp around a bit. It only makes a minor difference for selectany on global variables, so it goes well with the rest of this patch. http://reviews.llvm.org/D9042 llvm-svn: 235053
2015-04-16 07:04:24 +08:00
!isVarDeclStrongDefinition(Context, *this, cast<VarDecl>(D),
MS ABI: Aligned tentative definitions don't have CommonLinkage int __declspec(align(16)) foo; is a tentative definition but the storage for that variable should not have CommonLinkage. llvm-svn: 214828
2014-08-05 08:01:13 +08:00
CodeGenOpts.NoCommon))
CodeGen: Clean up CommonLinkage calculation No functionality change. llvm-svn: 205972
2014-04-11 00:53:16 +08:00
return llvm::GlobalVariable::CommonLinkage;
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
// selectany symbols are externally visible, so use weak instead of
// linkonce. MSVC optimizes away references to const selectany globals, so
// all definitions should be the same and ODR linkage should be used.
// http://msdn.microsoft.com/en-us/library/5tkz6s71.aspx
if (D->hasAttr<SelectAnyAttr>())
return llvm::GlobalVariable::WeakODRLinkage;
// Otherwise, we have strong external linkage.
assert(Linkage == GVA_StrongExternal);
Do the guarding of instantiated static data members on if its linkage is weak. Currently this is the case but may change in the future. (part of radar 8562966). llvm-svn: 117452
2010-10-28 00:21:54 +08:00
return llvm::GlobalVariable::ExternalLinkage;
implement support for basic codegen of global variables with no initializers. llvm-svn: 39795
2007-07-13 13:13:43 +08:00
}
Build enough support for aggregates to be able to compile this: void test(int A, _Complex float Y) { _Complex float X; X = X; } llvm-svn: 39669
2007-06-23 02:48:09 +08:00
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
llvm::GlobalValue::LinkageTypes CodeGenModule::getLLVMLinkageVarDefinition(
const VarDecl *VD, bool IsConstant) {
GVALinkage Linkage = getContext().GetGVALinkageForVariable(VD);
Don't dllimport/export destructor variants implemented by thunks. MSVC doesn't export these functions, so trying to import them doesnt' work. Also, don't let any dll attributes on the CXXDestructorDecl influence the thunk's linkage -- they should always be linkonce_odr. This takes care of the FIXME's for this in Nico's tests. Differential Revision: http://reviews.llvm.org/D3930 llvm-svn: 209706
2014-05-28 09:52:23 +08:00
return getLLVMLinkageForDeclarator(VD, Linkage, IsConstant);
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
}
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
/// Replace the uses of a function that was declared with a non-proto type.
/// We want to silently drop extra arguments from call sites
static void replaceUsesOfNonProtoConstant(llvm::Constant *old,
llvm::Function *newFn) {
// Fast path.
if (old->use_empty()) return;
llvm::Type *newRetTy = newFn->getReturnType();
SmallVector<llvm::Value*, 4> newArgs;
[WinEH] Update clang to use operand bundles on call sites This updates clang to use bundle operands to associate an invoke with the funclet which it is contained within. Depends on D15517. Differential Revision: http://reviews.llvm.org/D15518 llvm-svn: 255675
2015-12-16 05:27:59 +08:00
SmallVector<llvm::OperandBundleDef, 1> newBundles;
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
for (llvm::Value::use_iterator ui = old->use_begin(), ue = old->use_end();
ui != ue; ) {
llvm::Value::use_iterator use = ui++; // Increment before the use is erased.
[C++11] Update Clang for the change to LLVM's Use-Def chain iterators in r203364: what was use_iterator is now user_iterator, and there is a use_iterator for directly iterating over the uses. This also switches to use the range-based APIs where appropriate. llvm-svn: 203365
2014-03-09 11:16:50 +08:00
llvm::User *user = use->getUser();
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
// Recognize and replace uses of bitcasts. Most calls to
// unprototyped functions will use bitcasts.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *bitcast = dyn_cast<llvm::ConstantExpr>(user)) {
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
if (bitcast->getOpcode() == llvm::Instruction::BitCast)
replaceUsesOfNonProtoConstant(bitcast, newFn);
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
continue;
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
}
// Recognize calls to the function.
llvm::CallSite callSite(user);
if (!callSite) continue;
[C++11] Update Clang for the change to LLVM's Use-Def chain iterators in r203364: what was use_iterator is now user_iterator, and there is a use_iterator for directly iterating over the uses. This also switches to use the range-based APIs where appropriate. llvm-svn: 203365
2014-03-09 11:16:50 +08:00
if (!callSite.isCallee(&*use)) continue;
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
// If the return types don't match exactly, then we can't
// transform this call unless it's dead.
if (callSite->getType() != newRetTy && !callSite->use_empty())
continue;
// Get the call site's attribute list.
[IR] Take func, ret, and arg attrs separately in AttributeList::get This seems like a much more natural API, based on Derek Schuff's comments on r300015. It further hides the implementation detail of AttributeList that function attributes come last and appear at index ~0U, which is easy for the user to screw up. git diff says it saves code as well: 97 insertions(+), 137 deletions(-) This also makes it easier to change the implementation, which I want to do next. llvm-svn: 300153
2017-04-13 08:58:09 +08:00
SmallVector<llvm::AttributeSet, 8> newArgAttrs;
Update Clang for LLVM rename AttributeSet -> AttributeList llvm-svn: 298394
2017-03-22 00:57:30 +08:00
llvm::AttributeList oldAttrs = callSite.getAttributes();
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
// If the function was passed too few arguments, don't transform.
unsigned newNumArgs = newFn->arg_size();
if (callSite.arg_size() < newNumArgs) continue;
// If extra arguments were passed, we silently drop them.
// If any of the types mismatch, we don't transform.
unsigned argNo = 0;
bool dontTransform = false;
[IR] Take func, ret, and arg attrs separately in AttributeList::get This seems like a much more natural API, based on Derek Schuff's comments on r300015. It further hides the implementation detail of AttributeList that function attributes come last and appear at index ~0U, which is easy for the user to screw up. git diff says it saves code as well: 97 insertions(+), 137 deletions(-) This also makes it easier to change the implementation, which I want to do next. llvm-svn: 300153
2017-04-13 08:58:09 +08:00
for (llvm::Argument &A : newFn->args()) {
if (callSite.getArgument(argNo)->getType() != A.getType()) {
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
dontTransform = true;
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
break;
}
When rewriting a call to a K&R function to lead to a well-prototyped function, be sure to drop parameter attributes when dropping their associated arguments. Patch by Aaron Landwehr! llvm-svn: 136753
2011-08-03 08:43:55 +08:00
// Add any parameter attributes.
[IR] Make getParamAttributes take argument numbers, not ArgNo+1 Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1, Kind) everywhere. The fact that the AttributeList index for an argument is ArgNo+1 should be a hidden implementation detail. NFC llvm-svn: 300272
2017-04-14 07:12:13 +08:00
newArgAttrs.push_back(oldAttrs.getParamAttributes(argNo));
[IR] Take func, ret, and arg attrs separately in AttributeList::get This seems like a much more natural API, based on Derek Schuff's comments on r300015. It further hides the implementation detail of AttributeList that function attributes come last and appear at index ~0U, which is easy for the user to screw up. git diff says it saves code as well: 97 insertions(+), 137 deletions(-) This also makes it easier to change the implementation, which I want to do next. llvm-svn: 300153
2017-04-13 08:58:09 +08:00
argNo++;
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
}
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
if (dontTransform)
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
continue;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
// Okay, we can transform this. Create the new call instruction and copy
// over the required information.
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
newArgs.append(callSite.arg_begin(), callSite.arg_begin() + argNo);
[WinEH] Update clang to use operand bundles on call sites This updates clang to use bundle operands to associate an invoke with the funclet which it is contained within. Depends on D15517. Differential Revision: http://reviews.llvm.org/D15518 llvm-svn: 255675
2015-12-16 05:27:59 +08:00
// Copy over any operand bundles.
callSite.getOperandBundlesAsDefs(newBundles);
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
llvm::CallSite newCall;
if (callSite.isCall()) {
[WinEH] Update clang to use operand bundles on call sites This updates clang to use bundle operands to associate an invoke with the funclet which it is contained within. Depends on D15517. Differential Revision: http://reviews.llvm.org/D15518 llvm-svn: 255675
2015-12-16 05:27:59 +08:00
newCall = llvm::CallInst::Create(newFn, newArgs, newBundles, "",
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
callSite.getInstruction());
} else {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *oldInvoke = cast<llvm::InvokeInst>(callSite.getInstruction());
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
newCall = llvm::InvokeInst::Create(newFn,
oldInvoke->getNormalDest(),
oldInvoke->getUnwindDest(),
[WinEH] Update clang to use operand bundles on call sites This updates clang to use bundle operands to associate an invoke with the funclet which it is contained within. Depends on D15517. Differential Revision: http://reviews.llvm.org/D15518 llvm-svn: 255675
2015-12-16 05:27:59 +08:00
newArgs, newBundles, "",
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
callSite.getInstruction());
}
newArgs.clear(); // for the next iteration
if (!newCall->getType()->isVoidTy())
newCall->takeName(callSite.getInstruction());
[IR] Take func, ret, and arg attrs separately in AttributeList::get This seems like a much more natural API, based on Derek Schuff's comments on r300015. It further hides the implementation detail of AttributeList that function attributes come last and appear at index ~0U, which is easy for the user to screw up. git diff says it saves code as well: 97 insertions(+), 137 deletions(-) This also makes it easier to change the implementation, which I want to do next. llvm-svn: 300153
2017-04-13 08:58:09 +08:00
newCall.setAttributes(llvm::AttributeList::get(
newFn->getContext(), oldAttrs.getFnAttributes(),
oldAttrs.getRetAttributes(), newArgAttrs));
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
newCall.setCallingConv(callSite.getCallingConv());
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
// Finally, remove the old call, replacing any uses with the new one.
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
if (!callSite->use_empty())
callSite->replaceAllUsesWith(newCall.getInstruction());
Do not check use_empty() before invoking replaceAllUsesWith(). Let replaceAllUsesWith() adjust VHs even though there are no uses. llvm-svn: 83978
2009-10-14 01:02:04 +08:00
adjust to IRBuilder change and use faster DebugLoc apis. llvm-svn: 100093
2010-04-01 14:31:43 +08:00
// Copy debug location attached to CI.
DebugInfo: Use new LLVM API for DebugLoc Use the new API for `DebugLoc` added in r233573 before the old one disappears. llvm-svn: 233589
2015-03-31 04:01:41 +08:00
if (callSite->getDebugLoc())
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
newCall->setDebugLoc(callSite->getDebugLoc());
[WinEH] Update clang to use operand bundles on call sites This updates clang to use bundle operands to associate an invoke with the funclet which it is contained within. Depends on D15517. Differential Revision: http://reviews.llvm.org/D15518 llvm-svn: 255675
2015-12-16 05:27:59 +08:00
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
callSite->eraseFromParent();
When defining a function whose type has no prototype, make an effort to go back and clean up existing uses of the bitcasted function. This is not just an optimization: it is required for correctness to get always inline functions to work, see testcases in function-attributes.c. llvm-svn: 70971
2009-05-05 14:16:31 +08:00
}
}
Rewrite calls to bitcast unprototyped functions when emitting a definition. My variadics patch, r169588, changed these calls to typically be bitcasts rather than calls to a supposedly variadic function. This totally subverted a hack where we intentionally dropped excess arguments from such calls in order to appease the inliner and a "warning" from the optimizer. This patch extends the hack to also work with bitcasts, as well as teaching it to rewrite invokes. llvm-svn: 170034
2012-12-13 06:21:47 +08:00
/// ReplaceUsesOfNonProtoTypeWithRealFunction - This function is called when we
/// implement a function with no prototype, e.g. "int foo() {}". If there are
/// existing call uses of the old function in the module, this adjusts them to
/// call the new function directly.
///
/// This is not just a cleanup: the always_inline pass requires direct calls to
/// functions to be able to inline them. If there is a bitcast in the way, it
/// won't inline them. Instcombine normally deletes these calls, but it isn't
/// run at -O0.
static void ReplaceUsesOfNonProtoTypeWithRealFunction(llvm::GlobalValue *Old,
llvm::Function *NewFn) {
// If we're redefining a global as a function, don't transform it.
if (!isa<llvm::Function>(Old)) return;
replaceUsesOfNonProtoConstant(Old, NewFn);
}
Replace MarkVarRequired with a more generic HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios. llvm-svn: 152320
2012-03-08 23:51:03 +08:00
void CodeGenModule::HandleCXXStaticMemberVarInstantiation(VarDecl *VD) {
[CodeGen] Treat imported static local variables as declarations Imported variables cannot really be definitions for the purposes of IR generation. llvm-svn: 275040
2016-07-11 12:28:21 +08:00
auto DK = VD->isThisDeclarationADefinition();
if (DK == VarDecl::Definition && VD->hasAttr<DLLImportAttr>())
return;
Replace MarkVarRequired with a more generic HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios. llvm-svn: 152320
2012-03-08 23:51:03 +08:00
TemplateSpecializationKind TSK = VD->getTemplateSpecializationKind();
// If we have a definition, this might be a deferred decl. If the
// instantiation is explicit, make sure we emit it at the end.
if (VD->getDefinition() && TSK == TSK_ExplicitInstantiationDefinition)
GetAddrOfGlobalVar(VD);
In Sema::InstantiateStaticDataMemberDefinition, pass the var decl to the consumer just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with ASTConsumer::HandleTopLevelDecl. ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls; a consumer can treat an instantiated static data member however it wants of course. llvm-svn: 175976
2013-02-24 08:05:01 +08:00
EmitTopLevelDecl(VD);
Fix a small difference in sema and codegen views of what needs to be output. In the included testcase, soma thinks that we already have a definition after we see the out of line decl. Codegen puts it in a deferred list, to be output if a use is seen. This would break when we saw an explicit template instantiation definition, since codegen would not be notified. This patch adds a method to the consumer interface so that soma can notify codegen that this decl is now required. llvm-svn: 152024
2012-03-05 18:54:55 +08:00
}
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
Save another call to GetAddrOfFunction. Thread an optional GV down to EmitGlobalFunctionDefinition so that it can avoid the lookup when we already know the corresponding llvm global value. llvm-svn: 196789
2013-12-10 00:01:03 +08:00
void CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
llvm::GlobalValue *GV) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *D = cast<FunctionDecl>(GD.getDecl());
Use the "undergoes default argument promotion" bit on parameters to simplify the logic of initializing function parameters so that we don't need both a variable declaration and a type in FunctionArgList. This also means that we need to propagate the CGFunctionInfo down in a lot of places rather than recalculating it from the FAL. There's more we can do to eliminate redundancy here, and I've left FIXMEs behind to do it. llvm-svn: 127314
2011-03-09 12:27:21 +08:00
Fix three of the four places where I left breadcrumbs to avoid unnecessary recomputation. llvm-svn: 127322
2011-03-09 16:12:35 +08:00
// Compute the function info and LLVM type.
Whether an argument is required (in contrast with being an optional argument passed through the variadic ellipsis) potentially affects how we need to lower it. Propagate this information down to the various getFunctionInfo(...) overloads on CodeGenTypes. Furthermore, rename those overloads to clarify their distinct purposes, and make sure we're calling the right one in the right place. This has a nice side-effect of making it easier to construct a function type, since the 'variadic' bit is no longer separable. This shouldn't really change anything for our existing platforms, with one minor exception --- we should now call variadic ObjC methods with the ... in the "right place" (see the test case), which I guess matters for anyone running GNUStep on MIPS. Mostly it's just a substantial clean-up. llvm-svn: 150788
2012-02-17 11:33:10 +08:00
const CGFunctionInfo &FI = getTypes().arrangeGlobalDeclaration(GD);
llvm::FunctionType *Ty = getTypes().GetFunctionType(FI);
Use the "undergoes default argument promotion" bit on parameters to simplify the logic of initializing function parameters so that we don't need both a variable declaration and a type in FunctionArgList. This also means that we need to propagate the CGFunctionInfo down in a lot of places rather than recalculating it from the FAL. There's more we can do to eliminate redundancy here, and I've left FIXMEs behind to do it. llvm-svn: 127314
2011-03-09 12:27:21 +08:00
cleanups, no functionality change. llvm-svn: 71590
2009-05-13 04:58:15 +08:00
// Get or create the prototype for the function.
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
if (!GV || (GV->getType()->getElementType() != Ty))
GV = cast<llvm::GlobalValue>(GetAddrOfFunction(GD, Ty, /*ForVTable=*/false,
/*DontDefer=*/true,
Introduce a type-safe enum for ForDefinition. llvm-svn: 288289
2016-12-01 07:25:13 +08:00
ForDefinition));
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
2015-08-31 21:20:44 +08:00
// Already emitted.
if (!GV->isDeclaration())
Revert "[CodeGen] Fix crash with duplicated mangled name." This reverts commit r234767, as it was breaking all ARM buildbots for two days and the assert is not in the code, making it difficult to spot the error, which would keep the bots red for a few more days. New errors were silently introduced because of this bug, and we don't want this to escalate. llvm-svn: 234983
2015-04-15 16:44:40 +08:00
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Ensure that static local variables in function templates inherit the visibility of their function. llvm-svn: 118065
2010-11-03 05:04:24 +08:00
// We need to set linkage and visibility on the function before
// generating code for it because various parts of IR generation
// want to propagate this information down (e.g. to local static
// declarations).
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *Fn = cast<llvm::Function>(GV);
[ms-cxxabi] Thread GlobalDecls through to CodeGenModule::getFunctionLinkage. This is so that we can give destructor variants different linkage later. Differential Revision: http://llvm-reviews.chandlerc.com/D819 llvm-svn: 183324
2013-06-06 01:49:37 +08:00
setFunctionLinkage(GD, Fn);
Get the dll storage class right for structors of classes exported/imported via explicit instantiation (PR23667) This is a follow-up to r238266. It turned out structors are codegened through a different path, and didn't get the storage class set in EmitGlobalFunctionDefinition. llvm-svn: 238443
2015-05-29 01:44:56 +08:00
setFunctionDLLStorageClass(GD, Fn);
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
Cleanup setFunctionDefinitionAttributes. Use more specific type, update comments and name style. llvm-svn: 208328
2014-05-08 23:26:12 +08:00
// FIXME: this is redundant with part of setFunctionDefinitionAttributes
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
setGlobalVisibility(Fn, D, ForDefinition);
Ensure that static local variables in function templates inherit the visibility of their function. llvm-svn: 118065
2010-11-03 05:04:24 +08:00
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
MaybeHandleStaticInExternC(D, Fn);
Use a trivial comdat for inline ctor/dtor when not using C5/D5. When combined with llvm not producing implicit comdats, not doing this would cause code bloat on ELF and link errors on COFF. llvm-svn: 226211
2015-01-16 05:36:08 +08:00
maybeSetTrivialComdat(*D, *Fn);
[patch][pr19848] Produce explicit comdats in clang. The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
2015-01-13 06:13:53 +08:00
Use the "undergoes default argument promotion" bit on parameters to simplify the logic of initializing function parameters so that we don't need both a variable declaration and a type in FunctionArgList. This also means that we need to propagate the CGFunctionInfo down in a lot of places rather than recalculating it from the FAL. There's more we can do to eliminate redundancy here, and I've left FIXMEs behind to do it. llvm-svn: 127314
2011-03-09 12:27:21 +08:00
CodeGenFunction(*this).GenerateCode(D, Fn, FI);
Add -fexceptions to Driver - Maps to LangOptions.Exceptions - Currently always off, should autoselect based on language. Update CodeGen to set unwind attribute on functions definitions based on LangOptions.Exceptions. - Still need to set attributes appropriately on calls. llvm-svn: 54643
2008-08-12 01:36:14 +08:00
Cleanup setFunctionDefinitionAttributes. Use more specific type, update comments and name style. llvm-svn: 208328
2014-05-08 23:26:12 +08:00
setFunctionDefinitionAttributes(D, Fn);
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
SetLLVMFunctionAttributesForDefinition(D, Fn);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove the ASTContext parameter from the attribute-related methods of Decl. The implementations of these methods can Use Decl::getASTContext() to get the ASTContext. This commit touches a lot of files since call sites for these methods are everywhere. I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it. llvm-svn: 74501
2009-06-30 10:34:44 +08:00
if (const ConstructorAttr *CA = D->getAttr<ConstructorAttr>())
Fix a number of issues w.r.t. emission of global for functions and aliases. - Attributes specific to a definition are only set when the definition is seen. - Alias generation is delayed until the end of the module; necessary since the alias may reference forward. - Fixes: PR2743, <rdr://6140807&6094512> - Improves: <rdr://6095112> (added XFAIL) Also, print module on verification failures. llvm-svn: 55966
2008-09-09 07:44:31 +08:00
AddGlobalCtor(Fn, CA->getPriority());
Remove the ASTContext parameter from the attribute-related methods of Decl. The implementations of these methods can Use Decl::getASTContext() to get the ASTContext. This commit touches a lot of files since call sites for these methods are everywhere. I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it. llvm-svn: 74501
2009-06-30 10:34:44 +08:00
if (const DestructorAttr *DA = D->getAttr<DestructorAttr>())
Fix a number of issues w.r.t. emission of global for functions and aliases. - Attributes specific to a definition are only set when the definition is seen. - Alias generation is delayed until the end of the module; necessary since the alias may reference forward. - Fixes: PR2743, <rdr://6140807&6094512> - Improves: <rdr://6095112> (added XFAIL) Also, print module on verification failures. llvm-svn: 55966
2008-09-09 07:44:31 +08:00
AddGlobalDtor(Fn, DA->getPriority());
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
if (D->hasAttr<AnnotateAttr>())
AddGlobalAnnotations(D, Fn);
Rework codegen emission of globals - No (intended) functionality change. - Primary purpose is to clearly separate (lazy) construction of globals that are a forward declaration or tentative definition from those that are the final definition. - Lazy construction is now encapsulated in GetAddrOf{Function,GlobalVar} while final definitions are constructed in EmitGlobal{Function,Var}Definition. - External interface for dealing with globals is now limited to EmitGlobal and GetAddrOf{Function,GlobalVar}. - Also updated helper functions dealing with statics, annotations, and ctors to be private. llvm-svn: 54179
2008-07-30 07:18:29 +08:00
}
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
void CodeGenModule::EmitAliasDefinition(GlobalDecl GD) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *D = cast<ValueDecl>(GD.getDecl());
Remove the ASTContext parameter from the attribute-related methods of Decl. The implementations of these methods can Use Decl::getASTContext() to get the ASTContext. This commit touches a lot of files since call sites for these methods are everywhere. I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it. llvm-svn: 74501
2009-06-30 10:34:44 +08:00
const AliasAttr *AA = D->getAttr<AliasAttr>();
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
assert(AA && "Not an alias?");
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef MangledName = getMangledName(GD);
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
Don't crash on a self-alias declaration We were crashing in CodeGen given input like this: int self_alias(void) __attribute__((weak, alias("self_alias"))); such a self-alias is invalid, but instead of diagnosing the situation, we'd proceed to produce IR for both the function declaration and the alias. Because we already had a function named 'self_alias', the alias could not be named the same thing, and so LLVM would pick a different name ('self_alias1' for example) for that value. When we later called CodeGenModule::checkAliases, we'd look up the IR value corresponding to the alias name, find the function declaration instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent this is simply to avoid creating the wrongly-named alias value in the first place and issue the diagnostic there (instead of in checkAliases). We detect a related cycle case in CodeGenModule::EmitAliasDefinition already, so this just adds a second such check. Even though the other test cases for this 'alias definition is part of a cycle' diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression test for this case. This is because I can't add this check to test/Sema/attr-alias-elf.c without disturbing the other test cases in that file. In order to avoid construction of the bad IR values, this diagnostic is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant declaration is not added to the Aliases vector). The other cycle checks are done within the CodeGenModule::checkAliases function based on the Aliases vector, called from CodeGenModule::Release. However, if there have been errors earlier, HandleTranslationUnit does not call Release, and so checkAliases is never called, and so none of the other diagnostics would be produced. Fixes PR23509. llvm-svn: 246882
2015-09-05 05:49:21 +08:00
if (AA->getAliasee() == MangledName) {
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
Diags.Report(AA->getLocation(), diag::err_cyclic_alias) << 0;
Don't crash on a self-alias declaration We were crashing in CodeGen given input like this: int self_alias(void) __attribute__((weak, alias("self_alias"))); such a self-alias is invalid, but instead of diagnosing the situation, we'd proceed to produce IR for both the function declaration and the alias. Because we already had a function named 'self_alias', the alias could not be named the same thing, and so LLVM would pick a different name ('self_alias1' for example) for that value. When we later called CodeGenModule::checkAliases, we'd look up the IR value corresponding to the alias name, find the function declaration instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent this is simply to avoid creating the wrongly-named alias value in the first place and issue the diagnostic there (instead of in checkAliases). We detect a related cycle case in CodeGenModule::EmitAliasDefinition already, so this just adds a second such check. Even though the other test cases for this 'alias definition is part of a cycle' diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression test for this case. This is because I can't add this check to test/Sema/attr-alias-elf.c without disturbing the other test cases in that file. In order to avoid construction of the bad IR values, this diagnostic is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant declaration is not added to the Aliases vector). The other cycle checks are done within the CodeGenModule::checkAliases function based on the Aliases vector, called from CodeGenModule::Release. However, if there have been errors earlier, HandleTranslationUnit does not call Release, and so checkAliases is never called, and so none of the other diagnostics would be produced. Fixes PR23509. llvm-svn: 246882
2015-09-05 05:49:21 +08:00
return;
}
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
// If there is a definition in the module, then it wins over the alias.
// This is dubious, but allow it to be safe. Just ignore the alias.
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
if (Entry && !Entry->isDeclaration())
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
New fix for pr17535. This is a fixed version of r193161. In order to handle void foo() __attribute__((alias("bar"))); void bar() {} void zed() __attribute__((alias("foo"))); it is not enough to delay aliases to the end of the TU, we have to do two passes over them to find if they are defined or not. This can be implemented by producing alias as we go and just doing the second pass at the end. This has the advantage that other parts of clang that were expecting alias to be processed in order don't have to be changed. This patch also handles cyclic aliases. llvm-svn: 193188
2013-10-23 03:26:13 +08:00
Aliases.push_back(GD);
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *DeclTy = getTypes().ConvertTypeForMem(D->getType());
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
// Create a reference to the named value. This ensures that it is emitted
// if a deferred decl.
llvm::Constant *Aliasee;
if (isa<llvm::FunctionType>(DeclTy))
Propagate calling convention for aliases and weakrefs. llvm-svn: 165343
2012-10-06 07:12:53 +08:00
Aliasee = GetOrCreateLLVMFunction(AA->getAliasee(), DeclTy, GD,
Re-land r124768, with a fix for PR9130. We now emit everything except unused implicit virtual member functions when building the vtable. llvm-svn: 124935
2011-02-05 12:35:53 +08:00
/*ForVTable=*/false);
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
else
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(),
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::PointerType::getUnqual(DeclTy),
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
/*D=*/nullptr);
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
// Create the new alias itself, but don't set a name yet.
Update for llvm api change. llvm-svn: 209077
2014-05-18 05:30:14 +08:00
auto *GA = llvm::GlobalAlias::create(
[opaque pointer type] Fix a few uses of PointerType::getElementType in favor of uses of types already available elsewhere These are a few cleanups I happened to have from trying to go in a different direction recently, so just flushing them out while I have them. llvm-svn: 247593
2015-09-15 02:38:22 +08:00
DeclTy, 0, llvm::Function::ExternalLinkage, "", Aliasee, &getModule());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
if (Entry) {
Update for llvm api change. Now that llvm cannot represent alias cycles, we have to diagnose erros just before trying to close the cycle. This degrades the errors a bit. The real solution is what it was before: if we want to provide good errors for these cases, we have to be able to find a clang level decl given a mangled name and produce the error from Sema. llvm-svn: 209008
2014-05-17 03:35:48 +08:00
if (GA->getAliasee() == Entry) {
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
Diags.Report(AA->getLocation(), diag::err_cyclic_alias) << 0;
Update for llvm api change. Now that llvm cannot represent alias cycles, we have to diagnose erros just before trying to close the cycle. This degrades the errors a bit. The real solution is what it was before: if we want to provide good errors for these cases, we have to be able to find a clang level decl given a mangled name and produce the error from Sema. llvm-svn: 209008
2014-05-17 03:35:48 +08:00
return;
}
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
assert(Entry->isDeclaration());
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
// If there is a declaration in the module, then we had an extern followed
// by the alias, as in:
// extern int test6();
// ...
// int test6() __attribute__((alias("test7")));
//
// Remove it and replace uses of it with the alias.
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
GA->takeName(Entry);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Update for LLVM API change. llvm-svn: 77492
2009-07-30 02:54:39 +08:00
Entry->replaceAllUsesWith(llvm::ConstantExpr::getBitCast(GA,
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
Entry->getType()));
Entry->eraseFromParent();
Change CodeGenModule to rely on the Module's symbol table instead of shadowing it in the GlobalDeclMap. Eliminates the string-uniquing requirement for mangled names, which should help C++ codegen times a little. Forces us to do string lookups instead of pointer lookups, which might hurt codegen times a little across the board. We'll see how it plays out. Removing the string-uniquing requirement implicitly fixes any bugs like PR6635 which arose from the fact that we had multiple uniquing tables for different kinds of identifiers. llvm-svn: 99012
2010-03-20 07:29:14 +08:00
} else {
Switch over to the new caching version of getMangledName. llvm-svn: 106549
2010-06-23 00:16:50 +08:00
GA->setName(MangledName);
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
// Set attributes which are particular to an alias; this is a
// specialization of the attributes which may be set on a global
// variable/function.
Avoid code duplication by calling setAliasAttributes in EmitAliasDefinition. llvm-svn: 219258
2014-10-08 08:00:09 +08:00
if (D->hasAttr<WeakAttr>() || D->hasAttr<WeakRefAttr>() ||
D->isWeakImported()) {
Refactor how attributes are set on values. - Pull out SetCommonAttributes, which handles the things common to aliases, methods, functions, and variables. - Pull out SetLLVMFunctionAttributesForDefinition, which handles the LLVM attributes which we only want to apply to a definition (like noinline and alwaysinline). - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes and specialized). - Kill SetFunctionAttributesForDefinition (inlined into sole caller). - Inline SetGVDefinitionAttributes into SetMethodAttributes and specialize. - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes. This is supposed to be a no functionality change commit, but I may have made a mistake. llvm-svn: 69036
2009-04-14 16:05:55 +08:00
GA->setLinkage(llvm::Function::WeakAnyLinkage);
}
CodeGen: Don't drop thread_local when emitting __thread aliases CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
2014-10-16 06:38:23 +08:00
if (const auto *VD = dyn_cast<VarDecl>(D))
if (VD->getTLSKind())
setTLSMode(GA, *VD);
Avoid code duplication by calling setAliasAttributes in EmitAliasDefinition. llvm-svn: 219258
2014-10-08 08:00:09 +08:00
setAliasAttributes(D, GA);
emit aliases as the definitions fly by, don't bother deferring until the end of the module. llvm-svn: 67482
2009-03-23 05:47:11 +08:00
}
[GCC] Attribute ifunc support in clang This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
2016-04-11 15:48:59 +08:00
void CodeGenModule::emitIFuncDefinition(GlobalDecl GD) {
const auto *D = cast<ValueDecl>(GD.getDecl());
const IFuncAttr *IFA = D->getAttr<IFuncAttr>();
assert(IFA && "Not an ifunc?");
StringRef MangledName = getMangledName(GD);
if (IFA->getResolver() == MangledName) {
Diags.Report(IFA->getLocation(), diag::err_cyclic_alias) << 1;
return;
}
// Report an error if some definition overrides ifunc.
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
if (Entry && !Entry->isDeclaration()) {
GlobalDecl OtherGD;
if (lookupRepresentativeDecl(MangledName, OtherGD) &&
DiagnosedConflictingDefinitions.insert(GD).second) {
Diags.Report(D->getLocation(), diag::err_duplicate_mangled_name);
Diags.Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
}
return;
}
Aliases.push_back(GD);
llvm::Type *DeclTy = getTypes().ConvertTypeForMem(D->getType());
llvm::Constant *Resolver =
GetOrCreateLLVMFunction(IFA->getResolver(), DeclTy, GD,
/*ForVTable=*/false);
llvm::GlobalIFunc *GIF =
llvm::GlobalIFunc::create(DeclTy, 0, llvm::Function::ExternalLinkage,
"", Resolver, &getModule());
if (Entry) {
if (GIF->getResolver() == Entry) {
Diags.Report(IFA->getLocation(), diag::err_cyclic_alias) << 1;
return;
}
assert(Entry->isDeclaration());
// If there is a declaration in the module, then we had an extern followed
// by the ifunc, as in:
// extern int test();
// ...
// int test() __attribute__((ifunc("resolver")));
//
// Remove it and replace uses of it with the ifunc.
GIF->takeName(Entry);
Entry->replaceAllUsesWith(llvm::ConstantExpr::getBitCast(GIF,
Entry->getType()));
Entry->eraseFromParent();
} else
GIF->setName(MangledName);
SetCommonAttributes(D, GIF);
}
Change intrinsic getter to take an ArrayRef, now that the underlying function in LLVM does. llvm-svn: 135155
2011-07-15 01:45:50 +08:00
llvm::Function *CodeGenModule::getIntrinsic(unsigned IID,
Move ArrayRef to LLVM.h and eliminate now-redundant qualifiers, patch by Jon Mulder! llvm-svn: 135855
2011-07-24 01:14:25 +08:00
ArrayRef<llvm::Type*> Tys) {
Second attempt at de-constifying LLVM Types in FunctionType::get(), StructType::get() and TargetData::getIntPtrType(). llvm-svn: 134982
2011-07-12 22:06:48 +08:00
return llvm::Intrinsic::getDeclaration(&getModule(), (llvm::Intrinsic::ID)IID,
Change intrinsic getter to take an ArrayRef, now that the underlying function in LLVM does. llvm-svn: 135155
2011-07-15 01:45:50 +08:00
Tys);
introduce a new CodeGenModule::getIntrinsic method, which wraps Intrinsic::getDeclaration, allowing much more terse code. llvm-svn: 45136
2007-12-18 08:25:38 +08:00
}
add the ability to get the llvm function corresponding to a library builtin. llvm-svn: 41633
2007-08-31 12:31:45 +08:00
clang-format my last commit (sorry, keep forgetting that) llvm-svn: 234129
2015-04-06 06:47:07 +08:00
static llvm::StringMapEntry<llvm::GlobalVariable *> &
GetConstantCFStringEntry(llvm::StringMap<llvm::GlobalVariable *> &Map,
const StringLiteral *Literal, bool TargetIsLSB,
bool &IsUTF16, unsigned &StringLength) {
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef String = Literal->getString();
Convert all uses of StringLiteral::getStrData() to StringLiteral::getString() and remove getStrData(). Patch by Peter Davies (with some tweaks). llvm-svn: 111229
2010-08-17 20:54:38 +08:00
unsigned NumBytes = String.size();
Factor out map lookup for CFString constants. llvm-svn: 76908
2009-07-24 06:52:48 +08:00
Revert "Switch a few clients over to StringLiteral::getString.", this is breaking some projects, but I don't have a test case yet. llvm-svn: 82539
2009-09-22 18:03:52 +08:00
// Check for simple case.
if (!Literal->containsNonAsciiOrNull()) {
StringLength = NumBytes;
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
return *Map.insert(std::make_pair(String, nullptr)).first;
Revert "Switch a few clients over to StringLiteral::getString.", this is breaking some projects, but I don't have a test case yet. llvm-svn: 82539
2009-09-22 18:03:52 +08:00
}
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
// Otherwise, convert the UTF8 literals into a string of shorts.
IsUTF16 = true;
Move UTF functions into namespace llvm. Summary: This lets people link against LLVM and their own version of the UTF library. I determined this only affects llvm, clang, lld, and lldb by running $ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq clang lld lldb llvm Tested with ninja lldb ninja check-clang check-llvm check-lld (ninja check-lldb doesn't complete for me with or without this patch.) Reviewers: rnk Subscribers: klimek, beanz, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D24996 llvm-svn: 282822
2016-09-30 08:38:45 +08:00
SmallVector<llvm::UTF16, 128> ToBuf(NumBytes + 1); // +1 for ending nulls.
const llvm::UTF8 *FromPtr = (const llvm::UTF8 *)String.data();
llvm::UTF16 *ToPtr = &ToBuf[0];
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Move UTF functions into namespace llvm. Summary: This lets people link against LLVM and their own version of the UTF library. I determined this only affects llvm, clang, lld, and lldb by running $ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq clang lld lldb llvm Tested with ninja lldb ninja check-clang check-llvm check-lld (ninja check-lldb doesn't complete for me with or without this patch.) Reviewers: rnk Subscribers: klimek, beanz, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D24996 llvm-svn: 282822
2016-09-30 08:38:45 +08:00
(void)llvm::ConvertUTF8toUTF16(&FromPtr, FromPtr + NumBytes, &ToPtr,
ToPtr + NumBytes, llvm::strictConversion);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Output UTF-16 string literals independent of host byte order. - Steve, can you take a look at this? It seems like this code should live elsewhere, and there is a FIXME about having Sema validates the UTF-8 to UTF-16 conversion. llvm-svn: 76915
2009-07-24 07:41:22 +08:00
// ConvertUTF8toUTF16 returns the length in ToPtr.
Factor out map lookup for CFString constants. llvm-svn: 76908
2009-07-24 06:52:48 +08:00
StringLength = ToPtr - &ToBuf[0];
Output UTF-16 string literals independent of host byte order. - Steve, can you take a look at this? It seems like this code should live elsewhere, and there is a FIXME about having Sema validates the UTF-8 to UTF-16 conversion. llvm-svn: 76915
2009-07-24 07:41:22 +08:00
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
// Add an explicit null.
*ToPtr = 0;
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
return *Map.insert(std::make_pair(
StringRef(reinterpret_cast<const char *>(ToBuf.data()),
(StringLength + 1) * 2),
nullptr)).first;
Factor out map lookup for CFString constants. llvm-svn: 76908
2009-07-24 06:52:48 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress
Factor out map lookup for CFString constants. llvm-svn: 76908
2009-07-24 06:52:48 +08:00
CodeGenModule::GetAddrOfConstantCFString(const StringLiteral *Literal) {
unsigned StringLength = 0;
bool isUTF16 = false;
clang-format my last commit (sorry, keep forgetting that) llvm-svn: 234129
2015-04-06 06:47:07 +08:00
llvm::StringMapEntry<llvm::GlobalVariable *> &Entry =
GetConstantCFStringEntry(CFConstantStringMap, Literal,
getDataLayout().isLittleEndian(), isUTF16,
StringLength);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
if (auto *C = Entry.second)
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(C, CharUnits::fromQuantity(C->getAlignment()));
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify a bunch of code to use the well-known LLVM IR types computed by CodeGenModule. llvm-svn: 149943
2012-02-07 08:39:47 +08:00
llvm::Constant *Zero = llvm::Constant::getNullValue(Int32Ty);
NeXT: Clean up constant CFString handling. - Use CodeGenModule::GetAddrOfConstantCFString Some tweaks of CodeGenModule::GetAddrOfConstantCFString llvm-svn: 55243
2008-08-24 02:37:06 +08:00
llvm::Constant *Zeros[] = { Zero, Zero };
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
use CreateRuntimeVariable to get __CFConstantStringClassReference instead of doing it manually (which might end up getting auto-renamed), fixing a FIXME. rdar://7065446 llvm-svn: 76079
2009-07-17 00:48:25 +08:00
// If we don't already have it, get __CFConstantStringClassReference.
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
if (!CFConstantStringClassRef) {
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
Update for LLVM API change. llvm-svn: 77514
2009-07-30 06:16:19 +08:00
Ty = llvm::ArrayType::get(Ty, 0);
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
llvm::Constant *GV =
CreateRuntimeVariable(Ty, "__CFConstantStringClassReference");
CodeGen: tweak CFString emission for COFF targets The `isa' member was previously not given the correct DLL Storage. Ensure that we give the `isa' constant `__CFConstantStringClassReference' the correct DLL storage. Default to dllimport unless an explicit specification gives it a dllexport storage. llvm-svn: 271361
2016-06-01 12:22:24 +08:00
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
if (getTriple().isOSBinFormatCOFF()) {
CodeGen: tweak CFString emission for COFF targets The `isa' member was previously not given the correct DLL Storage. Ensure that we give the `isa' constant `__CFConstantStringClassReference' the correct DLL storage. Default to dllimport unless an explicit specification gives it a dllexport storage. llvm-svn: 271361
2016-06-01 12:22:24 +08:00
IdentifierInfo &II = getContext().Idents.get(GV->getName());
TranslationUnitDecl *TUDecl = getContext().getTranslationUnitDecl();
DeclContext *DC = TranslationUnitDecl::castToDeclContext(TUDecl);
llvm::GlobalValue *CGV = cast<llvm::GlobalValue>(GV);
const VarDecl *VD = nullptr;
for (const auto &Result : DC->lookup(&II))
if ((VD = dyn_cast<VarDecl>(Result)))
break;
if (!VD || !VD->hasAttr<DLLExportAttr>()) {
CGV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
CGV->setLinkage(llvm::GlobalValue::ExternalLinkage);
} else {
CGV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
CGV->setLinkage(llvm::GlobalValue::ExternalLinkage);
}
}
NeXT: Clean up constant CFString handling. - Use CodeGenModule::GetAddrOfConstantCFString Some tweaks of CodeGenModule::GetAddrOfConstantCFString llvm-svn: 55243
2008-08-24 02:37:06 +08:00
// Decay array -> ptr
CodeGen: remove unnecessary else case Refactor the assignment so that its much more clear that the if-clause contains the lookup, and once cached is directly used. NFC. llvm-svn: 281150
2016-09-11 09:25:15 +08:00
CFConstantStringClassRef =
llvm::ConstantExpr::getGetElementPtr(Ty, GV, Zeros);
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Handle padding in the constant CFString struct. Fixes PR3046. llvm-svn: 59372
2008-11-16 02:54:24 +08:00
QualType CFTy = getContext().getCFConstantStringType();
NeXT: Clean up constant CFString handling. - Use CodeGenModule::GetAddrOfConstantCFString Some tweaks of CodeGenModule::GetAddrOfConstantCFString llvm-svn: 55243
2008-08-24 02:37:06 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *STy = cast<llvm::StructType>(getTypes().ConvertType(CFTy));
Handle padding in the constant CFString struct. Fixes PR3046. llvm-svn: 59372
2008-11-16 02:54:24 +08:00
ConstantBuilder -> ConstantInitBuilder for clarity, and move the member classes up to top level to allow forward declarations to name them. NFC. llvm-svn: 288079
2016-11-29 06:18:27 +08:00
ConstantInitBuilder Builder(*this);
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
auto Fields = Builder.beginStruct(STy);
Unifies the name-lookup mechanisms used in various parts of the AST and separates lexical name lookup from qualified name lookup. In particular: * Make DeclContext the central data structure for storing and looking up declarations within existing declarations, e.g., members of structs/unions/classes, enumerators in C++0x enums, members of C++ namespaces, and (later) members of Objective-C interfaces/implementations. DeclContext uses a lazily-constructed data structure optimized for fast lookup (array for small contexts, hash table for larger contexts). * Implement C++ qualified name lookup in terms of lookup into DeclContext. * Implement C++ unqualified name lookup in terms of qualified+unqualified name lookup (since unqualified lookup is not purely lexical in C++!) * Limit the use of the chains of declarations stored in IdentifierInfo to those names declared lexically. * Eliminate CXXFieldDecl, collapsing its behavior into FieldDecl. (FieldDecl is now a ScopedDecl). * Make RecordDecl into a DeclContext and eliminates its Members/NumMembers fields (since one can just iterate through the DeclContext to get the fields). llvm-svn: 60878
2008-12-12 00:49:14 +08:00
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
// Class pointer.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
Fields.add(cast<llvm::ConstantExpr>(CFConstantStringClassRef));
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
// Flags.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
Fields.addInt(IntTy, isUTF16 ? 0x07d0 : 0x07C8);
No need to append extra padding now that we don't create packed structs for simple cases like the constant string. llvm-svn: 79178
2009-08-16 13:55:31 +08:00
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
// String pointer.
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::Constant *C = nullptr;
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
if (isUTF16) {
Use llvm::makeArrayRef. NFC. llvm-svn: 248678
2015-09-27 11:44:08 +08:00
auto Arr = llvm::makeArrayRef(
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
reinterpret_cast<uint16_t *>(const_cast<char *>(Entry.first().data())),
Entry.first().size() / 2);
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
C = llvm::ConstantDataArray::get(VMContext, Arr);
} else {
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
C = llvm::ConstantDataArray::getString(VMContext, Entry.first());
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
}
Add target hook for setting symbol prefix and section of unicode string literals. llvm-svn: 68363
2009-04-03 08:57:44 +08:00
The `-fwritable-strings' flag doesn't make the backing store strings of all CFStrings writable. The strings (both Unicode and ASCII) should reside in a read-only section. E.g., __TEXT,__cstring instead of __DATA,__data. This is done by making the global variable created for the strings constant despite the value of that flag. <rdar://problem/10657500> llvm-svn: 147845
2012-01-10 16:46:39 +08:00
// Note: -fwritable-strings doesn't make the backing store strings of
// CFStrings writable. (See <rdar://problem/10657500>)
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV =
Use private linkage for utf-16 objc strings too. llvm-svn: 199709
2014-01-21 10:57:56 +08:00
new llvm::GlobalVariable(getModule(), C->getType(), /*isConstant=*/true,
llvm::GlobalValue::PrivateLinkage, C, ".str");
Update clang for D20348 Differential Revision: http://reviews.llvm.org/D20339 llvm-svn: 272710
2016-06-15 05:02:05 +08:00
GV->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
Allow targets to define minimum alignment for global variables This patch adds a new common code feature that allows platform code to request minimum alignment of global symbols. The background for this is that on SystemZ, the most efficient way to load addresses of global symbol is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction provides PC-relative addressing, but only to *even* addresses. For this reason, existing compilers will guarantee that global symbols are always aligned to at least 2. [ Since symbols would otherwise already use a default alignment based on their type, this will usually only affect global objects of character type or character arrays. ] GCC also allows creating symbols without that extra alignment by using explicit "aligned" attributes (which then need to be used on both definition and each use of the symbol). To enable support for this with Clang, this patch adds a TargetInfo::MinGlobalAlign variable that provides a global minimum for the alignment of every global object (unless overridden via explicit alignment attribute), and adds code to respect this setting. Within this patch, no platform actually sets the value to anything but the default 1, resulting in no change in behaviour on any existing target. This version of the patch incorporates feedback from reviews by Eric Christopher and John McCall. Thanks to all reviewers! Patch by Richard Sandiford. llvm-svn: 181210
2013-05-07 00:23:57 +08:00
// Don't enforce the target's minimum global alignment, since the only use
// of the string is via this class initializer.
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
CharUnits Align = isUTF16
? getContext().getTypeAlignInChars(getContext().ShortTy)
: getContext().getTypeAlignInChars(getContext().CharTy);
GV->setAlignment(Align.getQuantity());
// FIXME: We set the section explicitly to avoid a bug in ld64 224.1.
// Without it LLVM can merge the string with a non unnamed_addr one during
// LTO. Doing that changes the section it ends in, which surprises ld64.
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
if (getTriple().isOSBinFormatMachO())
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
GV->setSection(isUTF16 ? "__TEXT,__ustring"
: "__TEXT,__cstring,cstring_literals");
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
// String.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
llvm::Constant *Str =
[opaque pointer type] Correctly pass the pointee type when creating a GEP constant expression llvm-svn: 236751
2015-05-08 01:27:56 +08:00
llvm::ConstantExpr::getGetElementPtr(GV->getValueType(), GV, Zeros);
No need to append extra padding now that we don't create packed structs for simple cases like the constant string. llvm-svn: 79178
2009-08-16 13:55:31 +08:00
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
if (isUTF16)
// Cast the UTF16 string to the correct type.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
Str = llvm::ConstantExpr::getBitCast(Str, Int8PtrTy);
Fields.add(Str);
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
// String length.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
auto Ty = getTypes().ConvertType(getContext().LongTy);
Fields.addInt(cast<llvm::IntegerType>(Ty), StringLength);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment = getPointerAlign();
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
// The struct.
Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will need a second pass. llvm-svn: 287437
2016-11-19 16:17:24 +08:00
GV = Fields.finishAndCreateGlobal("_unnamed_cfstring_", Alignment,
/*isConstant=*/false,
llvm::GlobalVariable::PrivateLinkage);
CodeGen: simplify the logic a slight bit Move the definition of `getTriple()` into the header. It would just call `getTarget().getTriple()`. Inline the definition to allow the compiler to see the same amount of the layout as previously. Remove the more verbose `getTarget().getTriple()` in favour of `getTriple()`. llvm-svn: 281487
2016-09-14 23:17:46 +08:00
switch (getTriple().getObjectFormat()) {
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
case llvm::Triple::UnknownObjectFormat:
llvm_unreachable("unknown file format");
case llvm::Triple::COFF:
case llvm::Triple::ELF:
[WebAssembly] Add minimal support for the new wasm object format triple. llvm-svn: 292269
2017-01-18 05:46:38 +08:00
case llvm::Triple::Wasm:
CodeGen: tweak CFString section for COFF, ELF Place the structure data into `cfstring`. This both isolates the structures to permit coalescing in the future (by the linker) as well as ensures that it doesnt get marked as read-only data. The structures themselves are not read-only, only the string contents. llvm-svn: 274956
2016-07-09 09:59:51 +08:00
GV->setSection("cfstring");
CodeGen: tweak CFConstantStrings for COFF and ELF Adjust the constant CFString emission to emit into more appropriate sections on ELF and COFF targets. It would previously try to use MachO section names irrespective of the file format. llvm-svn: 271211
2016-05-31 00:23:07 +08:00
break;
case llvm::Triple::MachO:
GV->setSection("__DATA,__cfstring");
break;
}
Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue. llvm-svn: 222306
2014-11-19 11:06:06 +08:00
Entry.second = GV;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(GV, Alignment);
Implement code generation for constant CFStrings. llvm-svn: 41206
2007-08-21 08:21:21 +08:00
}
Implement support for -fwritable-strings and make the code generator merge string literals when it is not provided. llvm-svn: 44394
2007-11-28 13:34:05 +08:00
[codeview] omit debug locations for nested exprs unless column info enabled Summary: Microsoft Visual Studio expects debug locations to correspond to statements. We used to emit locations for expressions nested inside statements. This would confuse the debugger, causing it to stop multiple times on the same line and breaking the "step into specific" feature. This change inhibits the emission of debug locations for nested expressions when emitting CodeView debug information, unless column information is enabled. Fixes PR34312. Reviewers: rnk, zturner Reviewed By: rnk Subscribers: majnemer, echristo, aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D37529 llvm-svn: 312965
2017-09-12 06:11:57 +08:00
bool CodeGenModule::getExpressionLocationsEnabled() const {
return !CodeGenOpts.EmitCodeView || CodeGenOpts.DebugColumnInfo;
}
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
QualType CodeGenModule::getObjCFastEnumerationStateType() {
if (ObjCFastEnumerationStateType.isNull()) {
ASTContext: Refactor implicit record creation Tidy up built-in record creation to reduce code duplication. Continuation of r197336. llvm-svn: 197452
2013-12-17 09:22:38 +08:00
RecordDecl *D = Context.buildImplicitRecord("__objcFastEnumerationState");
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
D->startDefinition();
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
QualType FieldTypes[] = {
Context.UnsignedLongTy,
Context.getPointerType(Context.getObjCIdType()),
Context.getPointerType(Context.UnsignedLongTy),
Context.getConstantArrayType(Context.UnsignedLongTy,
llvm::APInt(32, 5), ArrayType::Normal, 0)
};
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
for (size_t i = 0; i < 4; ++i) {
FieldDecl *Field = FieldDecl::Create(Context,
D,
SourceLocation(),
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
SourceLocation(), nullptr,
FieldTypes[i], /*TInfo=*/nullptr,
/*BitWidth=*/nullptr,
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
/*Mutable=*/false,
PR13064: Store whether an in-class initializer uses direct or copy initialization, and use that information to produce the right kind of initialization during template instantiation. llvm-svn: 158288
2012-06-10 11:12:00 +08:00
ICIS_NoInit);
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
Field->setAccess(AS_public);
D->addDecl(Field);
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
D->completeDefinition();
ObjCFastEnumerationStateType = Context.getTagDeclType(D);
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Move the creation of the record type for the state of Objective-C fast enumerations from the ASTContext into CodeGen, so that we don't need to serialize it to AST files. This appears to be the last of the low-hanging fruit for SpecialTypes. llvm-svn: 137124
2011-08-10 01:23:49 +08:00
return ObjCFastEnumerationStateType;
}
Fix the representation of wide strings in the AST and IR so that it uses the native representation of integers for the elements. This fixes a bunch of nastiness involving treating wide strings as a series of bytes. Patch by Seth Cantrell. llvm-svn: 143417
2011-11-01 10:23:42 +08:00
llvm::Constant *
CodeGenModule::GetConstantArrayFromStringLiteral(const StringLiteral *E) {
assert(!E->getType()->isPointerType() && "Strings are always arrays");
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Fix the representation of wide strings in the AST and IR so that it uses the native representation of integers for the elements. This fixes a bunch of nastiness involving treating wide strings as a series of bytes. Patch by Seth Cantrell. llvm-svn: 143417
2011-11-01 10:23:42 +08:00
// Don't emit it as the address of the string, emit the string data itself
// as an inline array.
improve the code that handles IR generation of byte-sized string literals to avoid allocating an std::string. llvm-svn: 149924
2012-02-07 06:47:00 +08:00
if (E->getCharByteWidth() == 1) {
SmallString<64> Str(E->getString());
// Resize the string to the right size, which is indicated by its type.
const ConstantArrayType *CAT = Context.getAsConstantArrayType(E->getType());
Str.resize(CAT->getSize().getZExtValue());
return llvm::ConstantDataArray::getString(VMContext, Str, false);
}
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *AType = cast<llvm::ArrayType>(getTypes().ConvertType(E->getType()));
reapply the patches reverted in r149477, which enable ConstantDataArray. llvm-svn: 149801
2012-02-05 10:30:40 +08:00
llvm::Type *ElemTy = AType->getElementType();
unsigned NumElements = AType->getNumElements();
build wide strings with ConstantDataArray, just because we can. llvm-svn: 149928
2012-02-07 06:52:04 +08:00
// Wide strings have either 2-byte or 4-byte elements.
if (ElemTy->getPrimitiveSizeInBits() == 16) {
SmallVector<uint16_t, 32> Elements;
Elements.reserve(NumElements);
for(unsigned i = 0, e = E->getLength(); i != e; ++i)
Elements.push_back(E->getCodeUnit(i));
Elements.resize(NumElements);
return llvm::ConstantDataArray::get(VMContext, Elements);
reapply the patches reverted in r149477, which enable ConstantDataArray. llvm-svn: 149801
2012-02-05 10:30:40 +08:00
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
build wide strings with ConstantDataArray, just because we can. llvm-svn: 149928
2012-02-07 06:52:04 +08:00
assert(ElemTy->getPrimitiveSizeInBits() == 32);
SmallVector<uint32_t, 32> Elements;
Elements.reserve(NumElements);
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
build wide strings with ConstantDataArray, just because we can. llvm-svn: 149928
2012-02-07 06:52:04 +08:00
for(unsigned i = 0, e = E->getLength(); i != e; ++i)
Elements.push_back(E->getCodeUnit(i));
Elements.resize(NumElements);
return llvm::ConstantDataArray::get(VMContext, Elements);
Fix the representation of wide strings in the AST and IR so that it uses the native representation of integers for the elements. This fixes a bunch of nastiness involving treating wide strings as a series of bytes. Patch by Seth Cantrell. llvm-svn: 143417
2011-11-01 10:23:42 +08:00
}
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
static llvm::GlobalVariable *
GenerateStringLiteral(llvm::Constant *C, llvm::GlobalValue::LinkageTypes LT,
CodeGenModule &CGM, StringRef GlobalName,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment) {
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
// OpenCL v1.2 s6.5.3: a string literal is in the constant address space.
unsigned AddrSpace = 0;
if (CGM.getLangOpts().OpenCL)
AddrSpace = CGM.getContext().getTargetAddressSpace(LangAS::opencl_constant);
Add comdat to string literal variables on COFF. llvm-svn: 226317
2015-01-17 04:32:35 +08:00
llvm::Module &M = CGM.getModule();
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
// Create a global variable for this string
auto *GV = new llvm::GlobalVariable(
Add comdat to string literal variables on COFF. llvm-svn: 226317
2015-01-17 04:32:35 +08:00
M, C->getType(), !CGM.getLangOpts().WritableStrings, LT, C, GlobalName,
nullptr, llvm::GlobalVariable::NotThreadLocal, AddrSpace);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
GV->setAlignment(Alignment.getQuantity());
Update clang for D20348 Differential Revision: http://reviews.llvm.org/D20339 llvm-svn: 272710
2016-06-15 05:02:05 +08:00
GV->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
Revert r236879, "Do not emit thunks with available_externally linkage in comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
2015-05-10 05:10:07 +08:00
if (GV->isWeakForLinker()) {
assert(CGM.supportsCOMDAT() && "Only COFF uses weak string literals");
GV->setComdat(M.getOrInsertComdat(GV->getName()));
}
Add comdat to string literal variables on COFF. llvm-svn: 226317
2015-01-17 04:32:35 +08:00
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
return GV;
}
Add GetAddrOfConstantCString method - Returns addr of constant for argument + '\0'. - I couldn't think of a better name. - Move appropriate users of GetAddrOfConstantString to this. Rename getStringForStringLiteral to GetStringForStringLiteral. Add GetAddrOfConstantStringFromLiteral - This combines GetAddrOfConstantString and GetStringForStringLiteral. This method can be, but is not yet, more efficient. Change GetAddrOfConstantString to not add terminating '\0' - <rdar://problem/6140956> llvm-svn: 54768
2008-08-14 07:20:05 +08:00
/// GetAddrOfConstantStringFromLiteral - Return a pointer to a
/// constant array for the given string literal.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress
Fix for bug http://llvm.org/PR17427. Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
2014-10-09 16:45:04 +08:00
CodeGenModule::GetAddrOfConstantStringFromLiteral(const StringLiteral *S,
StringRef Name) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment = getContext().getAlignOfGlobalVarInChars(S->getType());
Pacify bots again - turns out my checkout was slightly polluted when I was reverting a olista01s change, and this pollution made it upstream during the revert checkin :/ Sorryemacs -nw lib/CodeGen/CodeGenModule.cpp llvm-svn: 208426
2014-05-10 00:28:56 +08:00
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
llvm::Constant *C = GetConstantArrayFromStringLiteral(S);
llvm::GlobalVariable **Entry = nullptr;
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
if (!LangOpts.WritableStrings) {
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
Entry = &ConstantStringMap[C];
if (auto GV = *Entry) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (Alignment.getQuantity() > GV->getAlignment())
GV->setAlignment(Alignment.getQuantity());
return ConstantAddress(GV, Alignment);
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
}
}
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
SmallString<256> MangledNameBuffer;
StringRef GlobalVariableName;
llvm::GlobalValue::LinkageTypes LT;
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
// Mangle the string literal if the ABI allows for it. However, we cannot
// do this if we are compiling with ASan or -fwritable-strings because they
// rely on strings having normal linkage.
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (!LangOpts.WritableStrings &&
!LangOpts.Sanitize.has(SanitizerKind::Address) &&
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
getCXXABI().getMangleContext().shouldMangleStringLiteral(S)) {
llvm::raw_svector_ostream Out(MangledNameBuffer);
getCXXABI().getMangleContext().mangleStringLiteral(S, Out);
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
LT = llvm::GlobalValue::LinkOnceODRLinkage;
GlobalVariableName = MangledNameBuffer;
} else {
LT = llvm::GlobalValue::PrivateLinkage;
Fix for bug http://llvm.org/PR17427. Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
2014-10-09 16:45:04 +08:00
GlobalVariableName = Name;
Make GetAddrOfConstantStringFromLiteral return a constant of the correct type. This doesn't have any visible effects at the moment because normally the implicit cast code forces the type to the expected type. llvm-svn: 88896
2009-11-16 13:55:46 +08:00
}
Fix the representation of wide strings in the AST and IR so that it uses the native representation of integers for the elements. This fixes a bunch of nastiness involving treating wide strings as a series of bytes. Patch by Seth Cantrell. llvm-svn: 143417
2011-11-01 10:23:42 +08:00
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
auto GV = GenerateStringLiteral(C, LT, *this, GlobalVariableName, Alignment);
if (Entry)
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
*Entry = GV;
[ASan] Print exact source location of global variables in error reports. See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the original feature request. Introduce llvm.asan.globals metadata, which Clang (or any other frontend) may use to report extra information about global variables to ASan instrumentation pass in the backend. This metadata replaces llvm.asan.dynamically_initialized_globals that was used to detect init-order bugs. llvm.asan.globals contains the following data for each global: 1) source location (file/line/column info); 2) whether it is dynamically initialized; 3) whether it is blacklisted (shouldn't be instrumented). Source location data is then emitted in the binary and can be picked up by ASan runtime in case it needs to print error report involving some global. For example: 0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40 These source locations are printed even if the binary doesn't have any debug info. This is an ABI-breaking change. ASan initialization is renamed to __asan_init_v4(). Pre-built libraries compiled with older Clang will not work with the fresh runtime. llvm-svn: 212188
2014-07-03 00:54:41 +08:00
[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
SanitizerMD->reportGlobalToASan(GV, S->getStrTokenLoc(0), "<string literal>",
QualType());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(GV, Alignment);
Add GetAddrOfConstantCString method - Returns addr of constant for argument + '\0'. - I couldn't think of a better name. - Move appropriate users of GetAddrOfConstantString to this. Rename getStringForStringLiteral to GetStringForStringLiteral. Add GetAddrOfConstantStringFromLiteral - This combines GetAddrOfConstantString and GetStringForStringLiteral. This method can be, but is not yet, more efficient. Change GetAddrOfConstantString to not add terminating '\0' - <rdar://problem/6140956> llvm-svn: 54768
2008-08-14 07:20:05 +08:00
}
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
/// GetAddrOfConstantStringFromObjCEncode - Return a pointer to a constant
/// array for the given ObjCEncodeExpr node.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
CodeGenModule::GetAddrOfConstantStringFromObjCEncode(const ObjCEncodeExpr *E) {
std::string Str;
getContext().getObjCEncodingForType(E->getEncodedType(), Str);
Make constant emission for @encode use the common string emission code. This is a bit cleaner, and also "fixes" bad code that compares the addresses of the string constants. llvm-svn: 66346
2009-03-08 04:17:55 +08:00
return GetAddrOfConstantCString(Str);
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
}
Remove the overload of GetAddrOfConstantString method llvm-svn: 210214
2014-06-05 04:25:57 +08:00
/// GetAddrOfConstantCString - Returns a pointer to a character array containing
/// the literal and a terminating '\0' character.
Add GetAddrOfConstantCString method - Returns addr of constant for argument + '\0'. - I couldn't think of a better name. - Move appropriate users of GetAddrOfConstantString to this. Rename getStringForStringLiteral to GetStringForStringLiteral. Add GetAddrOfConstantStringFromLiteral - This combines GetAddrOfConstantString and GetStringForStringLiteral. This method can be, but is not yet, more efficient. Change GetAddrOfConstantString to not add terminating '\0' - <rdar://problem/6140956> llvm-svn: 54768
2008-08-14 07:20:05 +08:00
/// The result has pointer to array type.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress CodeGenModule::GetAddrOfConstantCString(
const std::string &Str, const char *GlobalName) {
Remove the overload of GetAddrOfConstantString method llvm-svn: 210214
2014-06-05 04:25:57 +08:00
StringRef StrWithNull(Str.c_str(), Str.size() + 1);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment =
getContext().getAlignOfGlobalVarInChars(getContext().CharTy);
Allow targets to define minimum alignment for global variables This patch adds a new common code feature that allows platform code to request minimum alignment of global symbols. The background for this is that on SystemZ, the most efficient way to load addresses of global symbol is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction provides PC-relative addressing, but only to *even* addresses. For this reason, existing compilers will guarantee that global symbols are always aligned to at least 2. [ Since symbols would otherwise already use a default alignment based on their type, this will usually only affect global objects of character type or character arrays. ] GCC also allows creating symbols without that extra alignment by using explicit "aligned" attributes (which then need to be used on both definition and each use of the symbol). To enable support for this with Clang, this patch adds a TargetInfo::MinGlobalAlign variable that provides a global minimum for the alignment of every global object (unless overridden via explicit alignment attribute), and adds code to respect this setting. Within this patch, no platform actually sets the value to anything but the default 1, resulting in no change in behaviour on any existing target. This version of the patch incorporates feedback from reviews by Eric Christopher and John McCall. Thanks to all reviewers! Patch by Richard Sandiford. llvm-svn: 181210
2013-05-07 00:23:57 +08:00
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
llvm::Constant *C =
llvm::ConstantDataArray::getString(getLLVMContext(), StrWithNull, false);
Add Target hooks for IRgen of [cf]string literals. - Notably, set section on cfstring literal string data (for now, this is done everywhere because it matches what we were already doing for the CFString data itself) - <rdar://problem/6599098> [irgen] linker requires objc string data to go into cstring llvm-svn: 68160
2009-04-01 07:42:16 +08:00
// Don't share any string literals if strings aren't constant.
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
llvm::GlobalVariable **Entry = nullptr;
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
if (!LangOpts.WritableStrings) {
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
Entry = &ConstantStringMap[C];
if (auto GV = *Entry) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (Alignment.getQuantity() > GV->getAlignment())
GV->setAlignment(Alignment.getQuantity());
return ConstantAddress(GV, Alignment);
Emit wide string literals with the appropriate alignment. Patch by Craig Topper and Sundeep! llvm-svn: 136856
2011-08-04 09:03:22 +08:00
}
}
Implement support for -fwritable-strings and make the code generator merge string literals when it is not provided. llvm-svn: 44394
2007-11-28 13:34:05 +08:00
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
// Get the default prefix if a name wasn't specified.
if (!GlobalName)
GlobalName = ".str";
Implement support for -fwritable-strings and make the code generator merge string literals when it is not provided. llvm-svn: 44394
2007-11-28 13:34:05 +08:00
// Create a global variable for this.
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral. Share mode code between these functions and re-structure them in a way which shows how similar they actually are. The latter function works well with literals of multi-byte chars and does a GlobalVariable name mangling (if global strings are non-writable). No functionality change. llvm-svn: 210212
2014-06-05 03:56:57 +08:00
auto GV = GenerateStringLiteral(C, llvm::GlobalValue::PrivateLinkage, *this,
GlobalName, Alignment);
if (Entry)
PR20473: Don't "deduplicate" string literals with the same value but different lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
2014-07-30 05:20:12 +08:00
*Entry = GV;
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(GV, Alignment);
Implement support for -fwritable-strings and make the code generator merge string literals when it is not provided. llvm-svn: 44394
2007-11-28 13:34:05 +08:00
}
Add GetAddrOfConstantCString method - Returns addr of constant for argument + '\0'. - I couldn't think of a better name. - Move appropriate users of GetAddrOfConstantString to this. Rename getStringForStringLiteral to GetStringForStringLiteral. Add GetAddrOfConstantStringFromLiteral - This combines GetAddrOfConstantString and GetStringForStringLiteral. This method can be, but is not yet, more efficient. Change GetAddrOfConstantString to not add terminating '\0' - <rdar://problem/6140956> llvm-svn: 54768
2008-08-14 07:20:05 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress CodeGenModule::GetAddrOfGlobalTemporary(
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
const MaterializeTemporaryExpr *E, const Expr *Init) {
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
assert((E->getStorageDuration() == SD_Static ||
E->getStorageDuration() == SD_Thread) && "not a global temporary");
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *VD = cast<VarDecl>(E->getExtendingDecl());
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
// If we're not materializing a subobject of the temporary, keep the
// cv-qualifiers from the type of the MaterializeTemporaryExpr.
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
QualType MaterializedType = Init->getType();
if (Init == E->GetTemporaryExpr())
MaterializedType = E->getType();
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Align = getContext().getTypeAlignInChars(MaterializedType);
Avoid iteration invalidation issues around MaterializedTemporaryExpr We risk iterator invalidation issues if we use a DenseMap to hold the backing storage for an APValue. Instead, BumpPtrAllocate them and use APValue * as our DenseMap value. Also, don't assume that MaterializedGlobalTemporaryMap won't regrow between when we initially perform a lookup and later on when we actually try to insert into it. This fixes PR24289. Differential Revision: http://reviews.llvm.org/D11629 llvm-svn: 244989
2015-08-14 07:50:15 +08:00
if (llvm::Constant *Slot = MaterializedGlobalTemporaryMap[E])
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return ConstantAddress(Slot, Align);
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
// FIXME: If an externally-visible declaration extends multiple temporaries,
// we need to give each temporary the same name in every translation unit (and
// we also need to make the temporaries externally-visible).
SmallString<256> Name;
llvm::raw_svector_ostream Out(Name);
AST: Mangle reference temporaries reliably Summary: Previously, we would generate a single name for all reference temporaries and allow LLVM to rename them for us. Instead, number the reference temporaries as we build them in Sema. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3554 llvm-svn: 207776
2014-05-02 01:50:17 +08:00
getCXXABI().getMangleContext().mangleReferenceTemporary(
VD, E->getManglingNumber(), Out);
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
APValue *Value = nullptr;
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
if (E->getStorageDuration() == SD_Static) {
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// We might have a cached constant initializer for this temporary. Note
// that this might have a different value from the value computed by
// evaluating the initializer if the surrounding constant expression
// modifies the temporary.
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
Value = getContext().getMaterializedTemporaryValue(E, false);
if (Value && Value->isUninit())
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
Value = nullptr;
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
}
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// Try evaluating it now, it might have a constant initializer.
Expr::EvalResult EvalResult;
if (!Value && Init->EvaluateAsRValue(EvalResult, getContext()) &&
!EvalResult.hasSideEffects())
Value = &EvalResult.Val;
Convert clang::LangAS to a strongly typed enum 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
2017-10-16 02:48:14 +08:00
LangAS AddrSpace =
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
VD ? GetGlobalVarAddressSpace(VD) : MaterializedType.getAddressSpace();
Optional<ConstantEmitter> emitter;
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::Constant *InitialValue = nullptr;
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
bool Constant = false;
llvm::Type *Type;
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
if (Value) {
// The temporary has a constant initializer, use it.
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
emitter.emplace(*this);
InitialValue = emitter->emitForInitializer(*Value, AddrSpace,
MaterializedType);
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
Constant = isTypeConstant(MaterializedType, /*ExcludeCtor*/Value);
Type = InitialValue->getType();
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
} else {
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// No initializer, the initialization will be provided when we
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
// initialize the declaration which performed lifetime extension.
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
Type = getTypes().ConvertTypeForMem(MaterializedType);
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
}
// Create a global variable for this lifetime-extended temporary.
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
llvm::GlobalValue::LinkageTypes Linkage =
getLLVMLinkageVarDefinition(VD, Constant);
CodeGen: static constexpr data members should have a linkonce_odr init Classes can be defined in multiple translation units. This means that the static constexpr data members should have identical initializers in all translation units. Implement this by giving the reference temporary linkonce_odr linkage. llvm-svn: 229900
2015-02-20 03:25:17 +08:00
if (Linkage == llvm::GlobalVariable::ExternalLinkage) {
const VarDecl *InitVD;
if (VD->isStaticDataMember() && VD->getAnyInitializer(InitVD) &&
isa<CXXRecordDecl>(InitVD->getLexicalDeclContext())) {
// Temporaries defined inside a class get linkonce_odr linkage because the
// class can be defined in multipe translation units.
Linkage = llvm::GlobalVariable::LinkOnceODRLinkage;
} else {
// There is no need for this temporary to have external linkage if the
// VarDecl has external linkage.
Linkage = llvm::GlobalVariable::InternalLinkage;
}
}
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
auto TargetAS = getContext().getTargetAddressSpace(AddrSpace);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = new llvm::GlobalVariable(
CodeGen: Fix linkage of reference temporaries Summary: A reference temporary should inherit the linkage of the variable it initializes. Otherwise, we may hit cases where a reference temporary wouldn't have the same value in all translation units. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3515 llvm-svn: 207451
2014-04-29 06:17:59 +08:00
getModule(), Type, Constant, Linkage, InitialValue, Name.c_str(),
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
/*InsertBefore=*/nullptr, llvm::GlobalVariable::NotThreadLocal, TargetAS);
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
if (emitter) emitter->finalize(GV);
Reland "Fix vtable not receiving hidden visibility when using push(visibility)" I had to reland this change in order to make the test work on windows This change should resolve https://bugs.llvm.org/show_bug.cgi?id=35022 https://reviews.llvm.org/D39627 llvm-svn: 319269
2017-11-29 08:54:20 +08:00
setGlobalVisibility(GV, VD, ForDefinition);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
GV->setAlignment(Align.getQuantity());
Revert r236879, "Do not emit thunks with available_externally linkage in comdats" It broke pecoff, at least i686-cygwin. llvm-svn: 236937
2015-05-10 05:10:07 +08:00
if (supportsCOMDAT() && GV->isWeakForLinker())
GV->setComdat(TheModule.getOrInsertComdat(GV->getName()));
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
if (VD->getTLSKind())
setTLSMode(GV, *VD);
CodeGen: Fix address space of global variable Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
2017-07-08 21:24:52 +08:00
llvm::Constant *CV = GV;
if (AddrSpace != LangAS::Default)
CV = getTargetCodeGenInfo().performAddrSpaceCast(
*this, GV, AddrSpace, LangAS::Default,
Type->getPointerTo(
getContext().getTargetAddressSpace(LangAS::Default)));
MaterializedGlobalTemporaryMap[E] = CV;
return ConstantAddress(CV, Align);
Model temporary lifetime-extension explicitly in the AST. Use this model to handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
2013-06-05 08:46:14 +08:00
}
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
/// EmitObjCPropertyImplementations - Emit information for synthesized
/// properties for an implementation.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
void CodeGenModule::EmitObjCPropertyImplementations(const
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
ObjCImplementationDecl *D) {
[C++11] Replacing ObjCCategoryDecl iterators propimpl_begin() and propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203930
2014-03-14 23:02:45 +08:00
for (const auto *PID : D->property_impls()) {
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
// Dynamic is just for type-checking.
if (PID->getPropertyImplementation() == ObjCPropertyImplDecl::Synthesize) {
ObjCPropertyDecl *PD = PID->getPropertyDecl();
// Determine which methods need to be implemented, some may have
Rename ObjCMethodDecl::isSynthesized to isPropertyAccessor. This more accurately reflects its use: this flag is set when a method matches the getter or setter name for a property in the same class, and does not actually specify whether or not the definition of the method will be synthesized (either implicitly or explicitly with @synthesize). This renames the setter and backing field as well, and changes the (soon-to-be-obsolete?) XML dump format to use 'property_accessor' instead of 'synthesized'. llvm-svn: 165626
2012-10-11 00:42:25 +08:00
// been overridden. Note that ::isPropertyAccessor is not the method
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
// we want, that just indicates if the decl came from a
// property. What we want to know is if the method is defined in
// this implementation.
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
if (!D->getInstanceMethod(PD->getGetterName()))
Support for implementation of property in the case where the synthesis is in an implementation of s subclass of a super class where the property has been declared. llvm-svn: 60792
2008-12-10 04:23:04 +08:00
CodeGenFunction(*this).GenerateObjCGetter(
const_cast<ObjCImplementationDecl *>(D), PID);
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
if (!PD->isReadOnly() &&
De-ASTContext-ify DeclContext. Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating". Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit. llvm-svn: 74506
2009-06-30 10:36:12 +08:00
!D->getInstanceMethod(PD->getSetterName()))
Support for implementation of property in the case where the synthesis is in an implementation of s subclass of a super class where the property has been declared. llvm-svn: 60792
2008-12-10 04:23:04 +08:00
CodeGenFunction(*this).GenerateObjCSetter(
const_cast<ObjCImplementationDecl *>(D), PID);
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
}
}
}
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
static bool needsDestructMethod(ObjCImplementationDecl *impl) {
Add a const overload for ObjCInterfaceDecl::all_declared_ivar_begin. This was previously not-const only because it has to lazily construct a chain of ivars the first time it is called (and after the chain is invalidated). In practice, all the clients were just const_casting their const Decls; all those now-unnecessary const_casts have been removed. llvm-svn: 135741
2011-07-22 10:08:32 +08:00
const ObjCInterfaceDecl *iface = impl->getClassInterface();
for (const ObjCIvarDecl *ivar = iface->all_declared_ivar_begin();
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
ivar; ivar = ivar->getNextIvar())
if (ivar->getType().isDestructedType())
return true;
return false;
}
[Objective-C++ IRGen] do not generate .cxx_construct for class that contains trivially-constructible struct ivar. rdar://18950072 llvm-svn: 221823
2014-11-13 06:37:43 +08:00
static bool AllTrivialInitializers(CodeGenModule &CGM,
ObjCImplementationDecl *D) {
CodeGenFunction CGF(CGM);
for (ObjCImplementationDecl::init_iterator B = D->init_begin(),
E = D->init_end(); B != E; ++B) {
CXXCtorInitializer *CtorInitExp = *B;
Expr *Init = CtorInitExp->getInit();
if (!CGF.isTrivialInitializer(Init))
return false;
}
return true;
}
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
/// EmitObjCIvarInitializations - Emit information for ivar initialization
/// for an implementation.
void CodeGenModule::EmitObjCIvarInitializations(ObjCImplementationDecl *D) {
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
// We might need a .cxx_destruct even if we don't have any ivar initializers.
if (needsDestructMethod(D)) {
IdentifierInfo *II = &getContext().Idents.get(".cxx_destruct");
Selector cxxSelector = getContext().Selectors.getSelector(0, &II);
ObjCMethodDecl *DTORMethod =
ObjCMethodDecl::Create(getContext(), D->getLocation(), D->getLocation(),
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
cxxSelector, getContext().VoidTy, nullptr, D,
Mark objc methods that are implicitly declared for properties (not user-declared) as implicit. This results in libclang ignoring such methods. llvm-svn: 137852
2011-08-18 03:25:08 +08:00
/*isInstance=*/true, /*isVariadic=*/false,
Rename ObjCMethodDecl::isSynthesized to isPropertyAccessor. This more accurately reflects its use: this flag is set when a method matches the getter or setter name for a property in the same class, and does not actually specify whether or not the definition of the method will be synthesized (either implicitly or explicitly with @synthesize). This renames the setter and backing field as well, and changes the (soon-to-be-obsolete?) XML dump format to use 'property_accessor' instead of 'synthesized'. llvm-svn: 165626
2012-10-11 00:42:25 +08:00
/*isPropertyAccessor=*/true, /*isImplicitlyDeclared=*/true,
Mark objc methods that are implicitly declared for properties (not user-declared) as implicit. This results in libclang ignoring such methods. llvm-svn: 137852
2011-08-18 03:25:08 +08:00
/*isDefined=*/false, ObjCMethodDecl::Required);
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
D->addInstanceMethod(DTORMethod);
CodeGenFunction(*this).GenerateObjCCtorDtorMethod(D, DTORMethod, false);
Set a special flag in class metadata when an Objective-C class has ivars that require destruction, but none that require anything except zero-initialization. This is common in ARC and (when true throughout a class hierarchy) permits the elimination of an unnecessary message-send during allocation. llvm-svn: 166088
2012-10-17 12:53:31 +08:00
D->setHasDestructors(true);
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
}
// If the implementation doesn't have any ivar initializers, we don't need
// a .cxx_construct.
[Objective-C++ IRGen] do not generate .cxx_construct for class that contains trivially-constructible struct ivar. rdar://18950072 llvm-svn: 221823
2014-11-13 06:37:43 +08:00
if (D->getNumIvarInitializers() == 0 ||
AllTrivialInitializers(*this, D))
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
return;
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
2011-03-22 15:05:39 +08:00
IdentifierInfo *II = &getContext().Idents.get(".cxx_construct");
Selector cxxSelector = getContext().Selectors.getSelector(0, &II);
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
// The constructor returns 'self'.
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
ObjCMethodDecl *CTORMethod = ObjCMethodDecl::Create(getContext(),
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
D->getLocation(),
Pass from the parser the locations of selector identifiers when creating objc method decls. They are not stored in the AST yet. llvm-svn: 140984
2011-10-03 14:36:36 +08:00
D->getLocation(),
cxxSelector,
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
getContext().getObjCIdType(),
nullptr, D, /*isInstance=*/true,
Mark objc methods that are implicitly declared for properties (not user-declared) as implicit. This results in libclang ignoring such methods. llvm-svn: 137852
2011-08-18 03:25:08 +08:00
/*isVariadic=*/false,
Rename ObjCMethodDecl::isSynthesized to isPropertyAccessor. This more accurately reflects its use: this flag is set when a method matches the getter or setter name for a property in the same class, and does not actually specify whether or not the definition of the method will be synthesized (either implicitly or explicitly with @synthesize). This renames the setter and backing field as well, and changes the (soon-to-be-obsolete?) XML dump format to use 'property_accessor' instead of 'synthesized'. llvm-svn: 165626
2012-10-11 00:42:25 +08:00
/*isPropertyAccessor=*/true,
Mark objc methods that are implicitly declared for properties (not user-declared) as implicit. This results in libclang ignoring such methods. llvm-svn: 137852
2011-08-18 03:25:08 +08:00
/*isImplicitlyDeclared=*/true,
/*isDefined=*/false,
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
ObjCMethodDecl::Required);
D->addInstanceMethod(CTORMethod);
CodeGenFunction(*this).GenerateObjCCtorDtorMethod(D, CTORMethod, true);
Set a special flag in class metadata when an Objective-C class has ivars that require destruction, but none that require anything except zero-initialization. This is common in ARC and (when true throughout a class hierarchy) permits the elimination of an unnecessary message-send during allocation. llvm-svn: 166088
2012-10-17 12:53:31 +08:00
D->setHasNonZeroConstructors(true);
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
}
Emit code for linkage specifications. llvm-svn: 68300
2009-04-02 13:55:18 +08:00
// EmitLinkageSpec - Emit all declarations in a linkage spec.
void CodeGenModule::EmitLinkageSpec(const LinkageSpecDecl *LSD) {
Don't error on C++ linkage; if we don't support that, there are serious issues :) llvm-svn: 77800
2009-08-02 04:48:04 +08:00
if (LSD->getLanguage() != LinkageSpecDecl::lang_c &&
LSD->getLanguage() != LinkageSpecDecl::lang_cxx) {
Emit code for linkage specifications. llvm-svn: 68300
2009-04-02 13:55:18 +08:00
ErrorUnsupported(LSD, "linkage spec");
return;
}
C++ Modules TS: Add parsing and some semantic analysis support for export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
2016-09-09 07:14:54 +08:00
EmitDeclContext(LSD);
}
void CodeGenModule::EmitDeclContext(const DeclContext *DC) {
for (auto *I : DC->decls()) {
// Unlike other DeclContexts, the contents of an ObjCImplDecl at TU scope
// are themselves considered "top-level", so EmitTopLevelDecl on an
// ObjCImplDecl does not recursively visit them. We need to do that in
// case they're nested inside another construct (LinkageSpecDecl /
// ExportDecl) that does stop them from being considered "top-level".
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
if (auto *OID = dyn_cast<ObjCImplDecl>(I)) {
[C++11] Replacing ObjCContainerDecl iterators meth_begin() and meth_end() with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203832
2014-03-14 03:03:34 +08:00
for (auto *M : OID->methods())
EmitTopLevelDecl(M);
objective-C IRGen: for @implementation nested in extern "C", its method definitions must be IRGen'ed before meta-data for class is generated. Otherwise, IRGen crashes (to say the least). // rdar://12581683 llvm-svn: 166809
2012-10-27 04:22:11 +08:00
}
C++ Modules TS: Add parsing and some semantic analysis support for export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
2016-09-09 07:14:54 +08:00
[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203278
2014-03-08 03:56:05 +08:00
EmitTopLevelDecl(I);
objective-C IRGen: for @implementation nested in extern "C", its method definitions must be IRGen'ed before meta-data for class is generated. Otherwise, IRGen crashes (to say the least). // rdar://12581683 llvm-svn: 166809
2012-10-27 04:22:11 +08:00
}
Emit code for linkage specifications. llvm-svn: 68300
2009-04-02 13:55:18 +08:00
}
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
/// EmitTopLevelDecl - Emit code for a single top level declaration.
void CodeGenModule::EmitTopLevelDecl(Decl *D) {
Move FunctionDecl::TemplateSpecializationInfo out into its own class, FunctionTemplateSpecializationInfo, in DeclTemplate.h. No functionality change. llvm-svn: 74431
2009-06-30 01:30:29 +08:00
// Ignore dependent declarations.
if (D->getDeclContext() && D->getDeclContext()->isDependentContext())
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
switch (D->getKind()) {
Emit conversion functions correctly. llvm-svn: 79985
2009-08-25 21:14:46 +08:00
case Decl::CXXConversion:
Add some basic support for generating C++ member functions. llvm-svn: 68425
2009-04-05 04:47:02 +08:00
case Decl::CXXMethod:
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
case Decl::Function:
Move FunctionDecl::TemplateSpecializationInfo out into its own class, FunctionTemplateSpecializationInfo, in DeclTemplate.h. No functionality change. llvm-svn: 74431
2009-06-30 01:30:29 +08:00
// Skip function templates
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
if (cast<FunctionDecl>(D)->getDescribedFunctionTemplate() ||
cast<FunctionDecl>(D)->isLateTemplateParsed())
Move FunctionDecl::TemplateSpecializationInfo out into its own class, FunctionTemplateSpecializationInfo, in DeclTemplate.h. No functionality change. llvm-svn: 74431
2009-06-30 01:30:29 +08:00
return;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
GlobalDecl doesn't have an explicit constructor anymore. llvm-svn: 81481
2009-09-11 07:43:36 +08:00
EmitGlobal(cast<FunctionDecl>(D));
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
// Always provide some coverage mapping
// even for the functions that aren't emitted.
AddDeferredUnusedCoverageMapping(D);
GlobalDecl doesn't have an explicit constructor anymore. llvm-svn: 81481
2009-09-11 07:43:36 +08:00
break;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
Fix assertion failure in codegen on non-template deduction guide. llvm-svn: 300762
2017-04-20 05:15:45 +08:00
case Decl::CXXDeductionGuide:
// Function-like, but does not result in code emission.
break;
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
case Decl::Var:
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
case Decl::Decomposition:
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
// Skip variable templates
if (cast<VarDecl>(D)->getDescribedVarTemplate())
return;
Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC. llvm-svn: 304649
2017-06-03 14:30:46 +08:00
LLVM_FALLTHROUGH;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
case Decl::VarTemplateSpecialization:
GlobalDecl doesn't have an explicit constructor anymore. llvm-svn: 81481
2009-09-11 07:43:36 +08:00
EmitGlobal(cast<VarDecl>(D));
P0217R3: code generation support for decomposition declarations. llvm-svn: 278642
2016-08-15 09:33:41 +08:00
if (auto *DD = dyn_cast<DecompositionDecl>(D))
for (auto *B : DD->bindings())
if (auto *HD = B->getHoldingVar())
EmitGlobal(HD);
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
Ignore indirect field declarations. Fixes PR9570. llvm-svn: 129337
2011-04-12 09:01:22 +08:00
// Indirect fields from global anonymous structs and unions can be
// ignored; only the actual variable requires IR gen support.
case Decl::IndirectField:
break;
Start attempting to generate code for C++ ctors. llvm-svn: 69168
2009-04-15 23:55:24 +08:00
// C++ Decls
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
case Decl::Namespace:
C++ Modules TS: Add parsing and some semantic analysis support for export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
2016-09-09 07:14:54 +08:00
EmitDeclContext(cast<NamespaceDecl>(D));
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
[c++17] Visit class template explicit specializations just like all other class definitions in codegen. If an explicit specialization has a static data member, it may be a definition and we may need to register it for emission. llvm-svn: 317296
2017-11-03 09:26:01 +08:00
case Decl::ClassTemplateSpecialization: {
const auto *Spec = cast<ClassTemplateSpecializationDecl>(D);
if (DebugInfo &&
Spec->getSpecializationKind() == TSK_ExplicitInstantiationDefinition &&
Spec->hasDefinition())
DebugInfo->completeTemplateDefinition(*Spec);
} LLVM_FALLTHROUGH;
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
case Decl::CXXRecord:
Modular Codegen: Support homing debug info for types in modular objects Matching the function-homing support for modular codegen. Any type implicitly (implicit template specializations) or explicitly defined in a module is attached to that module's object file and omitted elsewhere (only a declaration used if necessary for references). llvm-svn: 299987
2017-04-12 05:13:37 +08:00
if (DebugInfo) {
if (auto *ES = D->getASTContext().getExternalSource())
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
DebugInfo->completeUnusedClass(cast<CXXRecordDecl>(*D));
}
Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
2016-06-25 08:15:56 +08:00
// Emit any static data members, they may be definitions.
for (auto *I : cast<CXXRecordDecl>(D)->decls())
if (isa<VarDecl>(I) || isa<CXXRecordDecl>(I))
EmitTopLevelDecl(I);
break;
Parsing and AST support for using declarations, from John Thompson! llvm-svn: 73812
2009-06-20 08:51:54 +08:00
// No code generation needed.
Skip over shadow using decls during codegen. llvm-svn: 89079
2009-11-17 17:33:40 +08:00
case Decl::UsingShadow:
Keep track of function template specializations, to eliminate redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
2009-06-30 04:59:39 +08:00
case Decl::ClassTemplate:
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +08:00
case Decl::VarTemplate:
case Decl::VarTemplatePartialSpecialization:
Keep track of function template specializations, to eliminate redundant, implicit instantiations of function templates and provide a place where we can hang function template specializations. llvm-svn: 74454
2009-06-30 04:59:39 +08:00
case Decl::FunctionTemplate:
Implement support for C++0x alias templates. llvm-svn: 130953
2011-05-06 05:57:07 +08:00
case Decl::TypeAliasTemplate:
When inferring the result type of a block based on a return statement with a type-dependent expression, infer the placeholder type 'Context.DependentTy' to indicate that this is just a placeholder. Fixes PR9982 / <rdar://problem/9486685>. llvm-svn: 132657
2011-06-05 13:04:23 +08:00
case Decl::Block:
[Sema] Semantic analysis for empty-declaration and attribute-declaration. Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these attributes can be sema checked just as attributes attached to "normal" declarations. llvm-svn: 175900
2013-02-23 01:15:32 +08:00
case Decl::Empty:
Parsing and AST support for using declarations, from John Thompson! llvm-svn: 73812
2009-06-20 08:51:54 +08:00
break;
DebugInfo: imported_decl/using declarations at namespace scope llvm-svn: 201470
2014-02-16 05:03:07 +08:00
case Decl::Using: // using X; [C++]
if (CGDebugInfo *DI = getModuleDebugInfo())
DI->EmitUsingDecl(cast<UsingDecl>(*D));
return;
PR14606: Debug Info for namespace aliases/DW_TAG_imported_module This resolves the last of the PR14606 failures in the GDB 7.5 test suite. (but there are still unresolved issues in the imported_decl case - we need to implement optional/lazy decls for functions & variables like we already do for types) llvm-svn: 182329
2013-05-21 06:50:41 +08:00
case Decl::NamespaceAlias:
if (CGDebugInfo *DI = getModuleDebugInfo())
DI->EmitNamespaceAlias(cast<NamespaceAliasDecl>(*D));
return;
Support debug info for using directives at global/namespace scope. llvm-svn: 180594
2013-04-26 13:41:06 +08:00
case Decl::UsingDirective: // using namespace X; [C++]
if (CGDebugInfo *DI = getModuleDebugInfo())
DI->EmitUsingDirective(cast<UsingDirectiveDecl>(*D));
return;
Start attempting to generate code for C++ ctors. llvm-svn: 69168
2009-04-15 23:55:24 +08:00
case Decl::CXXConstructor:
Ignore constructor member templates in CodeGenModule::EmitTopLevelDecl. llvm-svn: 89737
2009-11-24 13:16:24 +08:00
// Skip function templates
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
if (cast<FunctionDecl>(D)->getDescribedFunctionTemplate() ||
cast<FunctionDecl>(D)->isLateTemplateParsed())
Ignore constructor member templates in CodeGenModule::EmitTopLevelDecl. llvm-svn: 89737
2009-11-24 13:16:24 +08:00
return;
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Emit the constructor for abstract classes when using -cxx-abi microsoft, fixes PR16735 llvm-svn: 187709
2013-08-05 01:30:04 +08:00
getCXXABI().EmitCXXConstructors(cast<CXXConstructorDecl>(D));
Start attempting to generate code for C++ ctors. llvm-svn: 69168
2009-04-15 23:55:24 +08:00
break;
Add support for generating (very basic) C++ destructors. These aren't called by anything yet. llvm-svn: 69343
2009-04-17 09:58:57 +08:00
case Decl::CXXDestructor:
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
2011-04-23 06:18:13 +08:00
if (cast<FunctionDecl>(D)->isLateTemplateParsed())
return;
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
getCXXABI().EmitCXXDestructors(cast<CXXDestructorDecl>(D));
Add support for generating (very basic) C++ destructors. These aren't called by anything yet. llvm-svn: 69343
2009-04-17 09:58:57 +08:00
break;
Don't assert when generating code with static_asserts. llvm-svn: 73208
2009-06-12 05:22:55 +08:00
case Decl::StaticAssert:
// Nothing to do.
break;
Start attempting to generate code for C++ ctors. llvm-svn: 69168
2009-04-15 23:55:24 +08:00
// Objective-C Decls
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
objc: Implemented variables declared in class interface whose sema decl is at the translation unit. llvm-svn: 67249
2009-03-19 06:33:24 +08:00
// Forward declarations, no (immediate) code generation.
Issue error if variables are defined inside an objc class, category or protocol. llvm-svn: 67450
2009-03-22 02:06:45 +08:00
case Decl::ObjCInterface:
Remove HasSynthBitfield and all callers/writers/etc. Also remove previous ResetObjCLayout calls since this is now handled in Sema. Part of rdar://11842763 llvm-svn: 160527
2012-07-20 06:22:55 +08:00
case Decl::ObjCCategory:
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
fix the two xfails I added with a previous patch by making ObjC interface types get completed when their definition is seen if previously laid out by the code generator. llvm-svn: 68177
2009-04-01 10:36:43 +08:00
Eliminate ObjCForwardProtocolDecl, which is redundant now that ObjCProtocolDecl modules forward declarations properly. llvm-svn: 147415
2012-01-02 05:23:57 +08:00
case Decl::ObjCProtocol: {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *Proto = cast<ObjCProtocolDecl>(D);
Eliminate ObjCForwardProtocolDecl, which is redundant now that ObjCProtocolDecl modules forward declarations properly. llvm-svn: 147415
2012-01-02 05:23:57 +08:00
if (Proto->isThisDeclarationADefinition())
ObjCRuntime->GenerateProtocol(Proto);
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
Eliminate ObjCForwardProtocolDecl, which is redundant now that ObjCProtocolDecl modules forward declarations properly. llvm-svn: 147415
2012-01-02 05:23:57 +08:00
}
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
case Decl::ObjCCategoryImpl:
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
// Categories have properties but don't support synthesize so we
// can ignore them here.
CodeGen: rename CodeGenModule::Runtime to ObjCRuntime llvm-svn: 136254
2011-07-28 04:29:46 +08:00
ObjCRuntime->GenerateCategory(cast<ObjCCategoryImplDecl>(D));
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
case Decl::ObjCImplementation: {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *OMD = cast<ObjCImplementationDecl>(D);
Objective-C @synthesize support. - Only supports simple assignment and atomic semantics are ignored. - Not quite usable yet because the methods do not actually get added to the class metadata. - Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain). - Rearrange CodeGenFunction so synthesis can reuse function prolog / epilog code. llvm-svn: 55365
2008-08-26 16:29:31 +08:00
EmitObjCPropertyImplementations(OMD);
IRGen for initialization/destruction of ivar class objects (NeXt runtime). (radar 7900343). llvm-svn: 102533
2010-04-29 05:28:56 +08:00
EmitObjCIvarInitializations(OMD);
CodeGen: rename CodeGenModule::Runtime to ObjCRuntime llvm-svn: 136254
2011-07-28 04:29:46 +08:00
ObjCRuntime->GenerateClass(OMD);
Enable debug info for objective c implementations that may not have an explicit instance variable. rdar://10590352 llvm-svn: 154481
2012-04-11 13:56:05 +08:00
// Emit global variable debug information.
if (CGDebugInfo *DI = getModuleDebugInfo())
Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend. llvm-svn: 259489
2016-02-02 19:06:51 +08:00
if (getCodeGenOpts().getDebugInfo() >= codegenoptions::LimitedDebugInfo)
Fix PR14474: don't emit debug info for interface types in -gline-tables-only mode. llvm-svn: 169138
2012-12-04 02:28:12 +08:00
DI->getOrCreateInterfaceType(getContext().getObjCInterfaceType(
OMD->getClassInterface()), OMD->getLocation());
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
}
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
case Decl::ObjCMethod: {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *OMD = cast<ObjCMethodDecl>(D);
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
// If this is not a prototype, emit the body.
Remove the ASTContext parameter from the getBody() methods of Decl and subclasses. Timings showed no significant difference before and after the commit. llvm-svn: 74504
2009-06-30 10:35:26 +08:00
if (OMD->getBody())
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
CodeGenFunction(*this).GenerateObjCMethod(OMD);
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
case Decl::ObjCCompatibleAlias:
Support @compatibility_alias at run time (GNUstep Runtime) Patch by Niels Grewe! llvm-svn: 149401
2012-02-01 02:59:20 +08:00
ObjCRuntime->RegisterAlias(cast<ObjCCompatibleAliasDecl>(D));
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
Serialize `#pragma comment`. `#pragma comment` was handled by Sema calling a function on ASTConsumer, and CodeGen then implementing this function and writing things to its output. Instead, introduce a PragmaCommentDecl AST node and hang one off the TranslationUnitDecl for every `#pragma comment` line, and then use the regular serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's eagerly deserialized.) http://reviews.llvm.org/D17799 llvm-svn: 262493
2016-03-03 01:28:48 +08:00
case Decl::PragmaComment: {
const auto *PCD = cast<PragmaCommentDecl>(D);
switch (PCD->getCommentKind()) {
case PCK_Unknown:
llvm_unreachable("unexpected pragma comment kind");
case PCK_Linker:
AppendLinkerOptions(PCD->getArg());
break;
case PCK_Lib:
AddDependentLib(PCD->getArg());
break;
case PCK_Compiler:
case PCK_ExeStr:
case PCK_User:
break; // We ignore all of these.
}
break;
}
Serialize `#pragma detect_mismatch`. This is like r262493, but for pragma detect_mismatch instead of pragma comment. The two pragmas have similar behavior, so use the same approach for both. llvm-svn: 262506
2016-03-03 03:28:54 +08:00
case Decl::PragmaDetectMismatch: {
const auto *PDMD = cast<PragmaDetectMismatchDecl>(D);
AddDetectMismatch(PDMD->getName(), PDMD->getValue());
break;
}
Emit code for linkage specifications. llvm-svn: 68300
2009-04-02 13:55:18 +08:00
case Decl::LinkageSpec:
EmitLinkageSpec(cast<LinkageSpecDecl>(D));
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
case Decl::FileScopeAsm: {
[cuda] treat file scope __asm as __host__ and ignore it during device-side compilation. Currently clang emits file-scope asm during *both* host and device compilation modes which is usually a wrong thing to do. There's no way to attach any attribute to an __asm statement, so there's no way to differentiate between host-side and device-side file-scope asm. This patch makes clang to match nvcc behavior and emit file-scope-asm only during host-side compilation. Differential Revision: http://reviews.llvm.org/D9270 llvm-svn: 235905
2015-04-28 02:52:00 +08:00
// File-scope asm is ignored during device-side CUDA compilation.
if (LangOpts.CUDA && LangOpts.CUDAIsDevice)
break;
[OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and device codegen. This patch attempts to fix the regressions identified when the patch was committed initially. Thanks to Michael Liao for identifying the fix in the offloading metadata generation related with side effects in evaluation of function arguments. llvm-svn: 256933
2016-01-06 21:42:12 +08:00
// File-scope asm is ignored during device-side OpenMP compilation.
if (LangOpts.OpenMPIsDevice)
break;
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *AD = cast<FileScopeAsmDecl>(D);
Simplify. llvm-svn: 232130
2015-03-13 08:54:30 +08:00
getModule().appendModuleInlineAsm(AD->getAsmString()->getString());
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
case Decl::Import: {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *Import = cast<ImportDecl>(D);
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
[modules] Don't emit initializers for VarDecls within a module eagerly whenever we first touch any part of that module. Instead, defer them until the first time that module is (transitively) imported. The initializer step for a module then recursively initializes modules that its own headers imported. For example, this avoids running the <iostream> global initializer in programs that don't actually use iostreams, but do use other parts of the standard library. llvm-svn: 276159
2016-07-21 03:10:16 +08:00
// If we've already imported this module, we're done.
if (!ImportedModules.insert(Import->getImportedModule()))
[modules] Don't eagerly deserialize so many ImportDecls. CodeGen basically ignores ImportDecls imported from modules, so only eagerly deserialize the ones from a PCH / preamble. llvm-svn: 245406
2015-08-19 10:30:28 +08:00
break;
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
[modules] Don't emit initializers for VarDecls within a module eagerly whenever we first touch any part of that module. Instead, defer them until the first time that module is (transitively) imported. The initializer step for a module then recursively initializes modules that its own headers imported. For example, this avoids running the <iostream> global initializer in programs that don't actually use iostreams, but do use other parts of the standard library. llvm-svn: 276159
2016-07-21 03:10:16 +08:00
// Emit debug information for direct imports.
if (!Import->getImportedOwningModule()) {
if (CGDebugInfo *DI = getModuleDebugInfo())
DI->EmitImportDecl(*Import);
}
Module: emit initializers in submodules when importing the parent module. When importing the parent module, module initializers in submodules should be emitted. rdar://28740482 llvm-svn: 284263
2016-10-15 02:55:44 +08:00
// Find all of the submodules and emit the module initializers.
llvm::SmallPtrSet<clang::Module *, 16> Visited;
SmallVector<clang::Module *, 16> Stack;
Visited.insert(Import->getImportedModule());
Stack.push_back(Import->getImportedModule());
while (!Stack.empty()) {
clang::Module *Mod = Stack.pop_back_val();
if (!EmittedModuleInitializers.insert(Mod).second)
continue;
for (auto *D : Context.getModuleInitializers(Mod))
EmitTopLevelDecl(D);
// Visit the submodules of this module.
for (clang::Module::submodule_iterator Sub = Mod->submodule_begin(),
SubEnd = Mod->submodule_end();
Sub != SubEnd; ++Sub) {
// Skip explicit children; they need to be explicitly imported to emit
// the initializers.
if ((*Sub)->IsExplicit)
continue;
if (Visited.insert(*Sub).second)
Stack.push_back(*Sub);
}
}
Implement parsing, AST, (de-)serialization, and placeholder global metadata for linking against the libraries/frameworks for imported modules. The module map language is extended with a new "link" directive that specifies what library or framework to link against when a module is imported, e.g., link "clangAST" or link framework "MyFramework" Importing the corresponding module (or any of its submodules) will eventually link against the named library/framework. For now, I've added some placeholder global metadata that encodes the imported libraries/frameworks, so that we can test that this information gets through to the IR. The format of the data is still under discussion. llvm-svn: 172437
2013-01-15 01:21:00 +08:00
break;
DebugInfo: Emit only the declaration of a class template that has an explicit instantiation declaration (& always emit such a type when there's an explicit instantiation definition) We should only have this optimization fire when the explicit instantiation definition would cause at least one member function to be emitted, thus ensuring that even a compiler not performing this optimization would still emit the full type information elsewhere. But we should also pessimize output still by always emitting the definition when the explicit instantiation definition appears so that at some point in the future we can depend on that information even when no code had to be emitted in that TU. (this shouldn't happen very often, since people mostly use explicit spec decl/defs to reduce code size - but perhaps one day they could use it to explicitly reduce debug info size too) This was worth about 2% for Clang and LLVM - so not a huge win, but a win. It looks really great for simple STL programs (include <string> and just declare a string - 14k -> 1.4k of .dwo) llvm-svn: 202769
2014-03-04 07:48:23 +08:00
}
C++ Modules TS: Add parsing and some semantic analysis support for export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
2016-09-09 07:14:54 +08:00
case Decl::Export:
EmitDeclContext(cast<ExportDecl>(D));
break;
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
case Decl::OMPThreadPrivate:
EmitOMPThreadPrivateDecl(cast<OMPThreadPrivateDecl>(D));
break;
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
case Decl::OMPDeclareReduction:
EmitOMPDeclareReduction(cast<OMPDeclareReductionDecl>(D));
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
default:
Reflow some comments. llvm-svn: 71937
2009-05-16 15:57:57 +08:00
// Make sure we handled everything we should, every other kind is a
// non-top-level decl. FIXME: Would be nice to have an isTopLevelDeclKind
// function. Need to recode Decl::Kind to do that easily.
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
assert(isa<TypeDecl>(D) && "Unsupported decl kind");
Add missing 'break's, found by inspection. No functionality change; the fallthrough happened to do the right thing in both cases. llvm-svn: 223064
2014-12-02 02:59:10 +08:00
break;
Clean up CodeGenModule interface. - Add CodeGenModule::EmitTopLevelDecl which uses switch on kind instead of ugly & slow dyn_cast chains. - Drop some simple forwarding methods into the ObjC runtime. - Privatize appropriate methods. llvm-svn: 54827
2008-08-16 07:26:23 +08:00
}
}
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
void CodeGenModule::AddDeferredUnusedCoverageMapping(Decl *D) {
// Do we need to generate coverage mapping?
if (!CodeGenOpts.CoverageMapping)
return;
switch (D->getKind()) {
case Decl::CXXConversion:
case Decl::CXXMethod:
case Decl::Function:
case Decl::ObjCMethod:
case Decl::CXXConstructor:
case Decl::CXXDestructor: {
InstrProf: Fix a misuse of the FunctionDecl API when generating coverage This was calling FD->hasBody(), meaning "Does the function that this decl refers to have a body?", rather than FD->doesThisDeclarationHaveABody(), meaning "Is this decl a non-deleted definition?". We might want to consider renaming these APIs :/ llvm-svn: 243360
2015-07-28 08:41:51 +08:00
if (!cast<FunctionDecl>(D)->doesThisDeclarationHaveABody())
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
return;
[Coverage] Add an option to emit limited coverage info Add an option to emit limited coverage info for unused decls. It's just a cl::opt for now to allow us to experiment quickly. When building llc, this results in an 84% size reduction in the llvm_covmap section, and a similar size reduction in the llvm_prf_names section. In practice I expect the size reduction to be roughly quadratic with the size of the program. The downside is that coverage for headers will no longer be complete. This will make the line/function/region coverage metrics incorrect, since they will be artificially high. One mitigation would be to somehow disable those metrics when using limited-coverage=true. This is related to: llvm.org/PR34533 (make SourceBasedCodeCoverage scale) Differential Revision: https://reviews.llvm.org/D38107 llvm-svn: 314002
2017-09-23 02:23:04 +08:00
SourceManager &SM = getContext().getSourceManager();
if (LimitedCoverage && SM.getMainFileID() != SM.getFileID(D->getLocStart()))
return;
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
auto I = DeferredEmptyCoverageMappingDecls.find(D);
if (I == DeferredEmptyCoverageMappingDecls.end())
DeferredEmptyCoverageMappingDecls[D] = true;
break;
}
default:
break;
};
}
void CodeGenModule::ClearUnusedCoverageMapping(const Decl *D) {
// Do we need to generate coverage mapping?
if (!CodeGenOpts.CoverageMapping)
return;
if (const auto *Fn = dyn_cast<FunctionDecl>(D)) {
if (Fn->isTemplateInstantiation())
ClearUnusedCoverageMapping(Fn->getTemplateInstantiationPattern());
}
auto I = DeferredEmptyCoverageMappingDecls.find(D);
if (I == DeferredEmptyCoverageMappingDecls.end())
DeferredEmptyCoverageMappingDecls[D] = false;
else
I->second = false;
}
void CodeGenModule::EmitDeferredUnusedCoverageMappings() {
[Coverage] Always emit unused coverage mappings in the same order. Non-determinism is confusing at best. Differential Revision: https://reviews.llvm.org/D41140 llvm-svn: 320533
2017-12-13 08:14:17 +08:00
for (const auto &Entry : DeferredEmptyCoverageMappingDecls) {
if (!Entry.second)
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
continue;
[Coverage] Always emit unused coverage mappings in the same order. Non-determinism is confusing at best. Differential Revision: https://reviews.llvm.org/D41140 llvm-svn: 320533
2017-12-13 08:14:17 +08:00
const Decl *D = Entry.first;
Add coverage mapping generation. This patch adds the '-fcoverage-mapping' option which allows clang to generate the coverage mapping information that can be used to provide code coverage analysis using the execution counts obtained from the instrumentation based profiling (-fprofile-instr-generate). llvm-svn: 214752
2014-08-05 02:41:51 +08:00
switch (D->getKind()) {
case Decl::CXXConversion:
case Decl::CXXMethod:
case Decl::Function:
case Decl::ObjCMethod: {
CodeGenPGO PGO(*this);
GlobalDecl GD(cast<FunctionDecl>(D));
PGO.emitEmptyCounterMapping(D, getMangledName(GD),
getFunctionLinkage(GD));
break;
}
case Decl::CXXConstructor: {
CodeGenPGO PGO(*this);
GlobalDecl GD(cast<CXXConstructorDecl>(D), Ctor_Base);
PGO.emitEmptyCounterMapping(D, getMangledName(GD),
getFunctionLinkage(GD));
break;
}
case Decl::CXXDestructor: {
CodeGenPGO PGO(*this);
GlobalDecl GD(cast<CXXDestructorDecl>(D), Dtor_Base);
PGO.emitEmptyCounterMapping(D, getMangledName(GD),
getFunctionLinkage(GD));
break;
}
default:
break;
};
}
}
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
/// Turns the given pointer into a constant.
static llvm::Constant *GetPointerConstant(llvm::LLVMContext &Context,
const void *Ptr) {
uintptr_t PtrInt = reinterpret_cast<uintptr_t>(Ptr);
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *i64 = llvm::Type::getInt64Ty(Context);
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
return llvm::ConstantInt::get(i64, PtrInt);
}
static void EmitGlobalDeclMetadata(CodeGenModule &CGM,
llvm::NamedMDNode *&GlobalMetadata,
GlobalDecl D,
llvm::GlobalValue *Addr) {
if (!GlobalMetadata)
GlobalMetadata =
CGM.getModule().getOrInsertNamedMetadata("clang.global.decl.ptrs");
// TODO: should we report variant information for ctors/dtors?
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::Metadata *Ops[] = {llvm::ConstantAsMetadata::get(Addr),
llvm::ConstantAsMetadata::get(GetPointerConstant(
CGM.getLLVMContext(), D.getDecl()))};
PR9214: Convert Metadata API to use ArrayRef. llvm-svn: 129929
2011-04-22 03:59:12 +08:00
GlobalMetadata->addOperand(llvm::MDNode::get(CGM.getLLVMContext(), Ops));
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
}
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
/// For each function which is declared within an extern "C" region and marked
/// as 'used', but has internal linkage, create an alias from the unmangled
/// name to the mangled name if possible. People expect to be able to refer
/// to such functions with an unmangled name from inline assembly within the
/// same translation unit.
void CodeGenModule::EmitStaticExternCAliases() {
[CUDA] Don't generate aliases for static extern "C" functions. Summary: These aliases are done to support inline asm, but there's nothing we can do: NVPTX doesn't support aliases. Reviewers: tra Subscribers: cfe-commits, jhen, echristo Differential Revision: http://reviews.llvm.org/D16501 llvm-svn: 258734
2016-01-26 06:36:37 +08:00
// Don't do anything if we're generating CUDA device code -- the NVPTX
// assembly target doesn't support aliases.
if (Context.getTargetInfo().getTriple().isNVPTX())
return;
C++11 rangify several loops. llvm-svn: 239528
2015-06-11 20:33:25 +08:00
for (auto &I : StaticExternCValues) {
IdentifierInfo *Name = I.first;
llvm::GlobalValue *Val = I.second;
Remove nondeterminism introduced in r178950. llvm-svn: 178952
2013-04-06 15:07:44 +08:00
if (Val && !getModule().getNamedValue(Name->getName()))
Update for llvm API change. Aliases in llvm now hold an arbitrary expression. llvm-svn: 210063
2014-06-03 10:42:01 +08:00
addUsedGlobal(llvm::GlobalAlias::create(Name->getName(), Val));
Remove nondeterminism introduced in r178950. llvm-svn: 178952
2013-04-06 15:07:44 +08:00
}
When an internal-linkage function or variable is declared within an extern "C" linkage specification, and is marked as __attribute__((used)), try to also give it the unmangled name (by emitting an internal linkage alias) if nothing else within the translation unit would use that name. This allows inline asm in that translation unit to use the entity via its unmangled name, which people apparently rely on. llvm-svn: 178950
2013-04-06 13:00:46 +08:00
}
Implement -Wframe-larger-than backend diagnostic Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning. This is the first GCC-compatible backend diagnostic built around LLVM's reporting feature. This commit adds infrastructure to perform reverse lookup from mangled names emitted after LLVM IR generation. We use that to resolve precise locations and originating AST functions, lambdas or block declarations to produce seamless codegen-guided diagnostics. An associated change, StringMap now maintains unique mangled name strings instead of allocating copies. This is a net memory saving in C++ and a small hit for C where we no longer reuse IdentifierInfo storage, pending further optimisation. llvm-svn: 210293
2014-06-06 06:10:59 +08:00
bool CodeGenModule::lookupRepresentativeDecl(StringRef MangledName,
GlobalDecl &Result) const {
auto Res = Manglings.find(MangledName);
if (Res == Manglings.end())
return false;
Result = Res->getValue();
return true;
}
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
/// Emits metadata nodes associating all the global values in the
/// current module with the Decls they came from. This is useful for
/// projects using IR gen as a subroutine.
///
/// Since there's currently no way to associate an MDNode directly
/// with an llvm::GlobalValue, we create a global named metadata
/// with the name 'clang.global.decl.ptrs'.
void CodeGenModule::EmitDeclMetadata() {
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::NamedMDNode *GlobalMetadata = nullptr;
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
refactor for-loop as range-loop before making changes. Differential Revision: http://reviews.llvm.org/D4176 llvm-svn: 212262
2014-07-03 17:30:29 +08:00
for (auto &I : MangledDeclNames) {
llvm::GlobalValue *Addr = getModule().getNamedValue(I.second);
Fix crash in EmitDeclMetadata mode Summary: This fixes a bug that's easily encountered in LLDB (https://llvm.org/bugs/show_bug.cgi?id=22875). The problem here is that we mangle a name during debug info emission, but never actually emit the actual Decl, so we run into problems in EmitDeclMetadata (which assumes such a Decl exists). Fix that by just skipping metadata emissions for mangled names that don't have associated Decls. Reviewers: rjmccall Subscribers: labath, cfe-commits Differential Revision: http://reviews.llvm.org/D13959 llvm-svn: 252229
2015-11-06 07:18:44 +08:00
// Some mangled names don't necessarily have an associated GlobalValue
// in this module, e.g. if we mangled it for DebugInfo.
if (Addr)
EmitGlobalDeclMetadata(*this, GlobalMetadata, I.first, Addr);
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
}
}
/// Emits metadata nodes for all the local variables in the current
/// function.
void CodeGenFunction::EmitDeclMetadata() {
if (LocalDeclMap.empty()) return;
llvm::LLVMContext &Context = getLLVMContext();
// Find the unique metadata ID for this name.
unsigned DeclPtrKind = Context.getMDKindID("clang.decl.ptr");
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::NamedMDNode *GlobalMetadata = nullptr;
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
refactor for-loop as range-loop before making changes. Differential Revision: http://reviews.llvm.org/D4176 llvm-svn: 212262
2014-07-03 17:30:29 +08:00
for (auto &I : LocalDeclMap) {
const Decl *D = I.first;
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Addr = I.second.getPointer();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *Alloca = dyn_cast<llvm::AllocaInst>(Addr)) {
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
llvm::Value *DAddr = GetPointerConstant(getLLVMContext(), D);
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
Alloca->setMetadata(
DeclPtrKind, llvm::MDNode::get(
Context, llvm::ValueAsMetadata::getConstant(DAddr)));
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
} else if (auto *GV = dyn_cast<llvm::GlobalValue>(Addr)) {
Provide a hook for the benefit of clients using clang IR gen as a subroutine: emit metadata associating allocas and global values with a Decl*. This feature is controlled by an option that (intentionally) cannot be enabled on the command line. To use this feature, simply set CodeGenOptions.EmitDeclMetadata = true; and then interpret the completely underspecified metadata. :) llvm-svn: 107739
2010-07-07 07:57:41 +08:00
GlobalDecl GD = GlobalDecl(cast<VarDecl>(D));
EmitGlobalDeclMetadata(CGM, GlobalMetadata, GD, GV);
}
}
}
IRgen: Move blocks runtime interfaces to CodeGenModule. llvm-svn: 108481
2010-07-16 08:00:15 +08:00
Emit a .ident saying that clang produced this file. Patch by Katya Romanova. llvm-svn: 192832
2013-10-17 03:28:50 +08:00
void CodeGenModule::EmitVersionIdentMetadata() {
llvm::NamedMDNode *IdentMetadata =
TheModule.getOrInsertNamedMetadata("llvm.ident");
std::string Version = getClangFullVersion();
llvm::LLVMContext &Ctx = TheModule.getContext();
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::Metadata *IdentNode[] = {llvm::MDString::get(Ctx, Version)};
Emit a .ident saying that clang produced this file. Patch by Katya Romanova. llvm-svn: 192832
2013-10-17 03:28:50 +08:00
IdentMetadata->addOperand(llvm::MDNode::get(Ctx, IdentNode));
}
Move the calling of emitTargetMD() later. Summary: Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz: extern char a[]; char f(){ return a[5];} char a[10]; Change MangledDeclNames to use a MapVector rather than a DenseMap so that the Metadata is output in order of original declaration, so to make deterministic and improve human readablity. Differential Revision: http://reviews.llvm.org/D4176 llvm-svn: 212263
2014-07-03 17:30:33 +08:00
void CodeGenModule::EmitTargetMetadata() {
Re-commit r214547 with tests fixed. Hopefully all the bots will be happy now. Original message: Fix iterator invalidation issues that are breaking my modules buildbot's bootstrap. llvm-svn: 214555
2014-08-02 04:39:36 +08:00
// Warning, new MangledDeclNames may be appended within this loop.
// We rely on MapVector insertions adding new elements to the end
// of the container.
// FIXME: Move this loop into the one target that needs it, and only
// loop over those declarations for which we couldn't emit the target
// metadata when we emitted the declaration.
for (unsigned I = 0; I != MangledDeclNames.size(); ++I) {
Actually fix problem with modules buildbot this time. llvm-svn: 214579
2014-08-02 06:17:28 +08:00
auto Val = *(MangledDeclNames.begin() + I);
Re-commit r214547 with tests fixed. Hopefully all the bots will be happy now. Original message: Fix iterator invalidation issues that are breaking my modules buildbot's bootstrap. llvm-svn: 214555
2014-08-02 04:39:36 +08:00
const Decl *D = Val.first.getDecl()->getMostRecentDecl();
llvm::GlobalValue *GV = GetGlobalValue(Val.second);
Move the calling of emitTargetMD() later. Summary: Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz: extern char a[]; char f(){ return a[5];} char a[10]; Change MangledDeclNames to use a MapVector rather than a DenseMap so that the Metadata is output in order of original declaration, so to make deterministic and improve human readablity. Differential Revision: http://reviews.llvm.org/D4176 llvm-svn: 212263
2014-07-03 17:30:33 +08:00
getTargetCodeGenInfo().emitTargetMD(D, GV, *this);
}
}
Preserve the full name of the file, so that '-c -o foo.pic.o' produces foo.pic.gcno instead of foo.gcno. llvm-svn: 130899
2011-05-05 08:08:20 +08:00
void CodeGenModule::EmitCoverageFile() {
Add -fprofile-dir= to clang. -fprofile-dir=path allows the user to specify where .gcda files should be emitted when the program is run. In particular, this is the first flag that causes the .gcno and .o files to have different paths, LLVM is extended to support this. -fprofile-dir= does not change the file name in the .gcno (and thus where lcov looks for the source) but it does change the name in the .gcda (and thus where the runtime library writes the .gcda file). It's different from a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX. To implement this we split -coverage-file into -coverage-data-file and -coverage-notes-file to specify the two different names. The !llvm.gcov metadata node grows from a 2-element form {string coverage-file, node dbg.cu} to 3-elements, {string coverage-notes-file, string coverage-data-file, node dbg.cu}. In the 3-element form, the file name is already "mangled" with .gcno/.gcda suffixes, while the 2-element form left that to the middle end pass. llvm-svn: 280306
2016-09-01 07:04:32 +08:00
if (getCodeGenOpts().CoverageDataFile.empty() &&
getCodeGenOpts().CoverageNotesFile.empty())
return;
llvm::NamedMDNode *CUNode = TheModule.getNamedMetadata("llvm.dbg.cu");
if (!CUNode)
return;
llvm::NamedMDNode *GCov = TheModule.getOrInsertNamedMetadata("llvm.gcov");
llvm::LLVMContext &Ctx = TheModule.getContext();
auto *CoverageDataFile =
llvm::MDString::get(Ctx, getCodeGenOpts().CoverageDataFile);
auto *CoverageNotesFile =
llvm::MDString::get(Ctx, getCodeGenOpts().CoverageNotesFile);
for (int i = 0, e = CUNode->getNumOperands(); i != e; ++i) {
llvm::MDNode *CU = CUNode->getOperand(i);
llvm::Metadata *Elts[] = {CoverageNotesFile, CoverageDataFile, CU};
GCov->addOperand(llvm::MDNode::get(Ctx, Elts));
Record where the GCOV data files should be placed. llvm-svn: 130866
2011-05-05 04:46:58 +08:00
}
}
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
Remove a parameter that has been unused since r188481. No behavior change. llvm-svn: 217386
2014-09-09 00:26:36 +08:00
llvm::Constant *CodeGenModule::EmitUuidofInitializer(StringRef Uuid) {
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
// Sema has checked that all uuid strings are of the form
// "12345678-1234-1234-1234-1234567890ab".
assert(Uuid.size() == 36);
CodeGen: __uuidof should work even with an incomplete _GUID type Summary: We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue will be foiled: the type of the constant value is incomplete. Instead, create an unnamed type with the proper layout on all platforms. Punt the problem of wrongly defined struct _GUID types to the user. (It's impossible because the TU may never get to see the type and thus we can't verify that it is suitable.) This fixes PR16856. Reviewers: rsmith, rnk, thakis Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1375 llvm-svn: 188481
2013-08-16 03:59:14 +08:00
for (unsigned i = 0; i < 36; ++i) {
if (i == 8 || i == 13 || i == 18 || i == 23) assert(Uuid[i] == '-');
else assert(isHexDigit(Uuid[i]));
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
}
CodeGen: __uuidof should work even with an incomplete _GUID type Summary: We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue will be foiled: the type of the constant value is incomplete. Instead, create an unnamed type with the proper layout on all platforms. Punt the problem of wrongly defined struct _GUID types to the user. (It's impossible because the TU may never get to see the type and thus we can't verify that it is suitable.) This fixes PR16856. Reviewers: rsmith, rnk, thakis Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1375 llvm-svn: 188481
2013-08-16 03:59:14 +08:00
Add a comment for something that confused me. llvm-svn: 217384
2014-09-09 00:11:15 +08:00
// The starts of all bytes of Field3 in Uuid. Field 3 is "1234-1234567890ab".
CodeGen: __uuidof should work even with an incomplete _GUID type Summary: We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue will be foiled: the type of the constant value is incomplete. Instead, create an unnamed type with the proper layout on all platforms. Punt the problem of wrongly defined struct _GUID types to the user. (It's impossible because the TU may never get to see the type and thus we can't verify that it is suitable.) This fixes PR16856. Reviewers: rsmith, rnk, thakis Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1375 llvm-svn: 188481
2013-08-16 03:59:14 +08:00
const unsigned Field3ValueOffsets[8] = { 19, 21, 24, 26, 28, 30, 32, 34 };
llvm::Constant *Field3[8];
for (unsigned Idx = 0; Idx < 8; ++Idx)
Field3[Idx] = llvm::ConstantInt::get(
Int8Ty, Uuid.substr(Field3ValueOffsets[Idx], 2), 16);
llvm::Constant *Fields[4] = {
llvm::ConstantInt::get(Int32Ty, Uuid.substr(0, 8), 16),
llvm::ConstantInt::get(Int16Ty, Uuid.substr(9, 4), 16),
llvm::ConstantInt::get(Int16Ty, Uuid.substr(14, 4), 16),
llvm::ConstantArray::get(llvm::ArrayType::get(Int8Ty, 8), Field3)
};
return llvm::ConstantStruct::getAnon(Fields);
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
}
CodeGen: Refactor RTTI emission Let's not expose ABI specific minutia inside of CodeGenModule and Type. Instead, let's abstract it through CXXABI. This gets rid of: CodeGenModule::getCompleteObjectLocator, CodeGenModule::EmitFundamentalTypeDescriptor{s,}, CodeGenModule::getMSTypeDescriptor, CodeGenModule::getMSCompleteObjectLocator, CGCXXABI::shouldRTTIBeUnique, CGCXXABI::classifyRTTIUniqueness. CGRTTI was *almost* entirely centered around providing Itanium-style RTTI information. Instead of providing interfaces that only it consumes, move it to the ItaniumCXXABI implementation file. This allows it to have access to Itanium-specific implementation details without providing useless expansion points for the Microsoft ABI side. Differential Revision: http://reviews.llvm.org/D4261 llvm-svn: 212435
2014-07-07 14:20:47 +08:00
llvm::Constant *CodeGenModule::GetAddrOfRTTIDescriptor(QualType Ty,
bool ForEH) {
// Return a bogus pointer if RTTI is disabled, unless it's for EH.
// FIXME: should we even be calling this method if RTTI is disabled
// and it's not for EH?
if (!ForEH && !getLangOpts().RTTI)
return llvm::Constant::getNullValue(Int8PtrTy);
Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change. Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317960
2017-11-11 09:15:41 +08:00
CodeGen: Refactor RTTI emission Let's not expose ABI specific minutia inside of CodeGenModule and Type. Instead, let's abstract it through CXXABI. This gets rid of: CodeGenModule::getCompleteObjectLocator, CodeGenModule::EmitFundamentalTypeDescriptor{s,}, CodeGenModule::getMSTypeDescriptor, CodeGenModule::getMSCompleteObjectLocator, CGCXXABI::shouldRTTIBeUnique, CGCXXABI::classifyRTTIUniqueness. CGRTTI was *almost* entirely centered around providing Itanium-style RTTI information. Instead of providing interfaces that only it consumes, move it to the ItaniumCXXABI implementation file. This allows it to have access to Itanium-specific implementation details without providing useless expansion points for the Microsoft ABI side. Differential Revision: http://reviews.llvm.org/D4261 llvm-svn: 212435
2014-07-07 14:20:47 +08:00
if (ForEH && Ty->isObjCObjectPointerType() &&
LangOpts.ObjCRuntime.isGNUFamily())
return ObjCRuntime->GetEHType(Ty);
WIP llvm-svn: 232537
2015-03-18 04:35:00 +08:00
return getCXXABI().getAddrOfRTTIDescriptor(Ty);
CodeGen: Refactor RTTI emission Let's not expose ABI specific minutia inside of CodeGenModule and Type. Instead, let's abstract it through CXXABI. This gets rid of: CodeGenModule::getCompleteObjectLocator, CodeGenModule::EmitFundamentalTypeDescriptor{s,}, CodeGenModule::getMSTypeDescriptor, CodeGenModule::getMSCompleteObjectLocator, CGCXXABI::shouldRTTIBeUnique, CGCXXABI::classifyRTTIUniqueness. CGRTTI was *almost* entirely centered around providing Itanium-style RTTI information. Instead of providing interfaces that only it consumes, move it to the ItaniumCXXABI implementation file. This allows it to have access to Itanium-specific implementation details without providing useless expansion points for the Microsoft ABI side. Differential Revision: http://reviews.llvm.org/D4261 llvm-svn: 212435
2014-07-07 14:20:47 +08:00
}
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
void CodeGenModule::EmitOMPThreadPrivateDecl(const OMPThreadPrivateDecl *D) {
for (auto RefExpr : D->varlists()) {
auto *VD = cast<VarDecl>(cast<DeclRefExpr>(RefExpr)->getDecl());
bool PerformInit =
VD->getAnyInitializer() &&
!VD->getAnyInitializer()->isConstantInitializer(getContext(),
/*ForRef=*/false);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Addr(GetAddrOfGlobalVar(VD), getContext().getDeclAlign(VD));
[OPENMP] Rename methods of OpenMPRuntime class. NFC. llvm-svn: 230470
2015-02-25 16:32:46 +08:00
if (auto InitFunction = getOpenMPRuntime().emitThreadPrivateVarDefinition(
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
VD, Addr, RefExpr->getLocStart(), PerformInit))
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
CXXGlobalInits.push_back(InitFunction);
}
}
CodeGen: Factor out some of the bitset entry creation code. NFC. llvm-svn: 239927
2015-06-18 03:08:05 +08:00
CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType. This function can be used to create a metadata identifier for a specific type. No functionality change, but this will be used by D11857 and D12026. Differential Revision: http://reviews.llvm.org/D12038 llvm-svn: 247098
2015-09-09 07:01:30 +08:00
llvm::Metadata *CodeGenModule::CreateMetadataIdentifierForType(QualType T) {
llvm::Metadata *&InternalId = MetadataIdMap[T.getCanonicalType()];
if (InternalId)
return InternalId;
if (isExternallyVisible(T->getLinkage())) {
std::string OutName;
llvm::raw_string_ostream Out(OutName);
getCXXABI().getMangleContext().mangleTypeName(T, Out);
InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
} else {
InternalId = llvm::MDNode::getDistinct(getLLVMContext(),
llvm::ArrayRef<llvm::Metadata *>());
}
[CFI] Add CFI-icall pointer type generalization Summary: This change allows generalizing pointers in type signatures used for cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag. This works by 1) emitting an additional generalized type signature metadata node for functions and 2) llvm.type.test()ing for the generalized type for translation units with the flag specified. This flag is incompatible with -fsanitize-cfi-cross-dso because it would require emitting twice as many type hashes which would increase artifact size. Reviewers: pcc, eugenis Reviewed By: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D39358 llvm-svn: 317044
2017-11-01 06:39:44 +08:00
return InternalId;
}
// Generalize pointer types to a void pointer with the qualifiers of the
// originally pointed-to type, e.g. 'const char *' and 'char * const *'
// generalize to 'const void *' while 'char *' and 'const char **' generalize to
// 'void *'.
static QualType GeneralizeType(ASTContext &Ctx, QualType Ty) {
if (!Ty->isPointerType())
return Ty;
return Ctx.getPointerType(
QualType(Ctx.VoidTy).withCVRQualifiers(
Ty->getPointeeType().getCVRQualifiers()));
}
// Apply type generalization to a FunctionType's return and argument types
static QualType GeneralizeFunctionType(ASTContext &Ctx, QualType Ty) {
if (auto *FnType = Ty->getAs<FunctionProtoType>()) {
SmallVector<QualType, 8> GeneralizedParams;
for (auto &Param : FnType->param_types())
GeneralizedParams.push_back(GeneralizeType(Ctx, Param));
return Ctx.getFunctionType(
GeneralizeType(Ctx, FnType->getReturnType()),
GeneralizedParams, FnType->getExtProtoInfo());
}
if (auto *FnType = Ty->getAs<FunctionNoProtoType>())
return Ctx.getFunctionNoProtoType(
GeneralizeType(Ctx, FnType->getReturnType()));
llvm_unreachable("Encountered unknown FunctionType");
}
llvm::Metadata *CodeGenModule::CreateMetadataIdentifierGeneralized(QualType T) {
T = GeneralizeFunctionType(getContext(), T);
llvm::Metadata *&InternalId = GeneralizedMetadataIdMap[T.getCanonicalType()];
if (InternalId)
return InternalId;
if (isExternallyVisible(T->getLinkage())) {
std::string OutName;
llvm::raw_string_ostream Out(OutName);
getCXXABI().getMangleContext().mangleTypeName(T, Out);
Out << ".generalized";
InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
} else {
InternalId = llvm::MDNode::getDistinct(getLLVMContext(),
llvm::ArrayRef<llvm::Metadata *>());
}
CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType. This function can be used to create a metadata identifier for a specific type. No functionality change, but this will be used by D11857 and D12026. Differential Revision: http://reviews.llvm.org/D12038 llvm-svn: 247098
2015-09-09 07:01:30 +08:00
return InternalId;
}
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
/// Returns whether this module needs the "all-vtables" type identifier.
bool CodeGenModule::NeedAllVtablesTypeId() const {
[cfi] Safe handling of unaddressable vtable pointers (clang). Avoid crashing when printing diagnostics for vtable-related CFI errors. In diagnostic mode, the frontend does an additional check of the vtable pointer against the set of all known vtable addresses and lets the runtime handler know if it is safe to inspect the vtable. http://reviews.llvm.org/D16823 llvm-svn: 259716
2016-02-04 06:18:55 +08:00
// Returns true if at least one of vtable-based CFI checkers is enabled and
// is not in the trapping mode.
return ((LangOpts.Sanitize.has(SanitizerKind::CFIVCall) &&
!CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFIVCall)) ||
(LangOpts.Sanitize.has(SanitizerKind::CFINVCall) &&
!CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFINVCall)) ||
(LangOpts.Sanitize.has(SanitizerKind::CFIDerivedCast) &&
!CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFIDerivedCast)) ||
(LangOpts.Sanitize.has(SanitizerKind::CFIUnrelatedCast) &&
!CodeGenOpts.SanitizeTrap.has(SanitizerKind::CFIUnrelatedCast)));
}
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
void CodeGenModule::AddVTableTypeMetadata(llvm::GlobalVariable *VTable,
CharUnits Offset,
const CXXRecordDecl *RD) {
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
llvm::Metadata *MD =
CreateMetadataIdentifierForType(QualType(RD->getTypeForDecl(), 0));
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
VTable->addTypeMetadata(Offset.getQuantity(), MD);
Cross-DSO control flow integrity (Clang part). Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
2015-12-16 07:00:20 +08:00
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
if (CodeGenOpts.SanitizeCfiCrossDso)
if (auto CrossDsoTypeId = CreateCrossDsoCfiTypeId(MD))
VTable->addTypeMetadata(Offset.getQuantity(),
llvm::ConstantAsMetadata::get(CrossDsoTypeId));
[cfi] Safe handling of unaddressable vtable pointers (clang). Avoid crashing when printing diagnostics for vtable-related CFI errors. In diagnostic mode, the frontend does an additional check of the vtable pointer against the set of all known vtable addresses and lets the runtime handler know if it is safe to inspect the vtable. http://reviews.llvm.org/D16823 llvm-svn: 259716
2016-02-04 06:18:55 +08:00
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
if (NeedAllVtablesTypeId()) {
[cfi] Safe handling of unaddressable vtable pointers (clang). Avoid crashing when printing diagnostics for vtable-related CFI errors. In diagnostic mode, the frontend does an additional check of the vtable pointer against the set of all known vtable addresses and lets the runtime handler know if it is safe to inspect the vtable. http://reviews.llvm.org/D16823 llvm-svn: 259716
2016-02-04 06:18:55 +08:00
llvm::Metadata *MD = llvm::MDString::get(getLLVMContext(), "all-vtables");
CodeGen: Update Clang to use the new type metadata. Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
2016-06-25 05:21:46 +08:00
VTable->addTypeMetadata(Offset.getQuantity(), MD);
[cfi] Safe handling of unaddressable vtable pointers (clang). Avoid crashing when printing diagnostics for vtable-related CFI errors. In diagnostic mode, the frontend does an additional check of the vtable pointer against the set of all known vtable addresses and lets the runtime handler know if it is safe to inspect the vtable. http://reviews.llvm.org/D16823 llvm-svn: 259716
2016-02-04 06:18:55 +08:00
}
CodeGen: Factor out some of the bitset entry creation code. NFC. llvm-svn: 239927
2015-06-18 03:08:05 +08:00
}
Extract out a function onto CodeGenModule for getting the map of features for a particular function, then use it to clean up some code. llvm-svn: 252819
2015-11-12 07:05:08 +08:00
// Fills in the supplied string map with the set of target features for the
// passed in function.
void CodeGenModule::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
const FunctionDecl *FD) {
StringRef TargetCPU = Target.getTargetOpts().CPU;
if (const auto *TD = FD->getAttr<TargetAttr>()) {
// If we have a TargetAttr build up the feature map based on that.
TargetAttr::ParsedTargetAttr ParsedAttr = TD->parse();
Filter out invalid 'target' items from being passed to LLVM 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
2017-10-28 02:32:23 +08:00
ParsedAttr.Features.erase(
llvm::remove_if(ParsedAttr.Features,
[&](const std::string &Feat) {
return !Target.isValidFeatureName(
StringRef{Feat}.substr(1));
}),
ParsedAttr.Features.end());
Extract out a function onto CodeGenModule for getting the map of features for a particular function, then use it to clean up some code. llvm-svn: 252819
2015-11-12 07:05:08 +08:00
// Make a copy of the features as passed on the command line into the
// beginning of the additional features from the function to override.
Convert attribute 'target' parsing from a 'pair' to a 'struct' to make further improvements easier Convert attribute 'target' parsing from a 'pair' to a 'struct' to make further improvements easier The attribute 'target' parse function previously returned a pair. Convert this to a 'pair' in order to add more functionality, and improve usability. Differential Revision: https://reviews.llvm.org/D35574 llvm-svn: 308357
2017-07-19 04:41:02 +08:00
ParsedAttr.Features.insert(ParsedAttr.Features.begin(),
Extract out a function onto CodeGenModule for getting the map of features for a particular function, then use it to clean up some code. llvm-svn: 252819
2015-11-12 07:05:08 +08:00
Target.getTargetOpts().FeaturesAsWritten.begin(),
Target.getTargetOpts().FeaturesAsWritten.end());
Filter out invalid 'target' items from being passed to LLVM 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
2017-10-28 02:32:23 +08:00
if (ParsedAttr.Architecture != "" &&
Target.isValidCPUName(ParsedAttr.Architecture))
TargetCPU = ParsedAttr.Architecture;
Extract out a function onto CodeGenModule for getting the map of features for a particular function, then use it to clean up some code. llvm-svn: 252819
2015-11-12 07:05:08 +08:00
// Now populate the feature map, first with the TargetCPU which is either
// the default or a new one from the target attribute string. Then we'll use
// the passed in features (FeaturesAsWritten) along with the new ones from
// the attribute.
Convert attribute 'target' parsing from a 'pair' to a 'struct' to make further improvements easier Convert attribute 'target' parsing from a 'pair' to a 'struct' to make further improvements easier The attribute 'target' parse function previously returned a pair. Convert this to a 'pair' in order to add more functionality, and improve usability. Differential Revision: https://reviews.llvm.org/D35574 llvm-svn: 308357
2017-07-19 04:41:02 +08:00
Target.initFeatureMap(FeatureMap, getDiags(), TargetCPU,
ParsedAttr.Features);
Extract out a function onto CodeGenModule for getting the map of features for a particular function, then use it to clean up some code. llvm-svn: 252819
2015-11-12 07:05:08 +08:00
} else {
Target.initFeatureMap(FeatureMap, getDiags(), TargetCPU,
Target.getTargetOpts().Features);
}
}
Introduce -fsanitize-stats flag. This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
2016-01-16 08:31:22 +08:00
llvm::SanitizerStatReport &CodeGenModule::getSanStats() {
if (!SanStats)
SanStats = llvm::make_unique<llvm::SanitizerStatReport>(&getModule());
return *SanStats;
}
[OpenCL] Generate opaque type for sampler_t and function call for the initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
2016-07-29 03:26:30 +08:00
llvm::Value *
CodeGenModule::createOpenCLIntToSamplerConversion(const Expr *E,
CodeGenFunction &CGF) {
Extract IRGen's constant-emitter into its own helper class and clean up the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
2017-08-16 05:42:52 +08:00
llvm::Constant *C = ConstantEmitter(CGF).emitAbstract(E, E->getType());
[OpenCL] Allow targets to select address space per type Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such that targets can select the address space per type. No functional changes intended. Initial patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D33989 llvm-svn: 310911
2017-08-15 17:38:18 +08:00
auto SamplerT = getOpenCLRuntime().getSamplerType(E->getType().getTypePtr());
[OpenCL] Generate opaque type for sampler_t and function call for the initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
2016-07-29 03:26:30 +08:00
auto FTy = llvm::FunctionType::get(SamplerT, {C->getType()}, false);
return CGF.Builder.CreateCall(CreateRuntimeFunction(FTy,
"__translate_sampler_initializer"),
{C});
}