summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Serialize `pragma ms_struct` state.Nico Weber2016-03-021-1/+11
| | | | | | | | | | | pragma ms_struct has an effect on struct decls, and the effect is serialized correctly already. But the "is ms_struct currently on" state wasn't before this change. This uses the same approach as `pragma clang optimize`: When writing a module, the state isn't serialized, only when writing a pch file. llvm-svn: 262539
* Generalize the consumed-parameter array on FunctionProtoTypeJohn McCall2016-03-011-1/+7
| | | | | | | | | to allow arbitrary data to be associated with a parameter. Also, fix a bug where we apparently haven't been serializing this information for the last N years. llvm-svn: 262278
* Fix rejects-valid caused by r261297.Nico Weber2016-02-241-0/+1
| | | | | | | | | | | | | | | | r261297 called hasUserProvidedDefaultConstructor() to check if defining a const object is ok. This is incorrect for this example: struct X { template<typename ...T> X(T...); int n; }; const X x; // formerly OK, now bogus error Instead, track if a class has a defaulted default constructor, and disallow a const object for classes that either have defaulted default constructors or if they need an implicit constructor. Bug report and fix approach by Richard Smith, thanks! llvm-svn: 261770
* Implement the likely resolution of core issue 253.Nico Weber2016-02-191-0/+1
| | | | | | | | | | | | | | | | | | C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
* [modules] Compress files embedded into a .pcm file, to reduce the disk usage ↵Richard Smith2016-02-061-16/+38
| | | | | | of -fembed-all-files mode. llvm-svn: 259976
* [modules] Separately track whether an identifier's preprocessor information andRichard Smith2016-02-051-1/+5
| | | | | | | | | | name lookup information have changed since deserialization. For a C++ modules build, we do not need to re-emit the identifier into the serialized identifier table if only the name lookup information has changed (and in all cases, we don't need to re-emit the macro information if only the name lookup information has changed). llvm-svn: 259901
* Fix predefine for __NSConstantString struct typeBen Langmuir2016-02-041-0/+2
| | | | | | | | | | | | | | | | | Per review feedback the name was wrong and it can be used outside Objective-C. Unfortunately, making the internal struct visible broke some ASTMatchers tests that assumed that the first record decl would be from user code, rather than a builtin type. I'm worried that this will also affect users' code. So this patch adds a typedef to wrap the internal struct and only makes the typedef visible to namelookup. This is sufficient to allow the ASTReader to merge the decls we need without making the struct itself visible. rdar://problem/24425801 llvm-svn: 259734
* Reapply r259624, it is likely not the commit causing the bot failures.Quentin Colombet2016-02-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original message: Make CF constant string decl visible to name lookup to fix module errors The return type of the __builtin___*StringMakeConstantString functions is a pointer to a struct, so we need that struct to be visible to name lookup so that we will correctly merge multiple declarations of that type if they come from different modules. Incidentally, to make this visible to name lookup we need to rename the type to __NSConstantString, since the real NSConstantString is an Objective-C interface type. This shouldn't affect anyone outside the compiler since users of the constant string builtins cast the result immediately to CFStringRef. Since this struct type is otherwise implicitly created by the AST context and cannot access namelookup, we make this a predefined type and initialize it in Sema. Note: this issue of builtins that refer to types not visible to name lookup technically also affects other builtins (e.g. objc_msgSendSuper), but in all other cases the builtin is a library builtin and the issue goes away if you include the library that defines the types it uses, unlike for these constant string builtins. rdar://problem/24425801 llvm-svn: 259721
* Revert r259624 - Make CF constant string decl visible to name lookup to fix ↵Quentin Colombet2016-02-031-2/+0
| | | | | | | | | module errors. This breaks some internal bots in stage2: clang seg fault. Looking with Ben to see what is going on. llvm-svn: 259715
* Make CF constant string decl visible to name lookup to fix module errorsBen Langmuir2016-02-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The return type of the __builtin___*StringMakeConstantString functions is a pointer to a struct, so we need that struct to be visible to name lookup so that we will correctly merge multiple declarations of that type if they come from different modules. Incidentally, to make this visible to name lookup we need to rename the type to __NSConstantString, since the real NSConstantString is an Objective-C interface type. This shouldn't affect anyone outside the compiler since users of the constant string builtins cast the result immediately to CFStringRef. Since this struct type is otherwise implicitly created by the AST context and cannot access namelookup, we make this a predefined type and initialize it in Sema. Note: this issue of builtins that refer to types not visible to name lookup technically also affects other builtins (e.g. objc_msgSendSuper), but in all other cases the builtin is a library builtin and the issue goes away if you include the library that defines the types it uses, unlike for these constant string builtins. rdar://problem/24425801 llvm-svn: 259624
* [OpenCL] Pipe type supportXiuli Pan2016-01-091-0/+9
| | | | | | | | | | | | | | | Summary: Support for OpenCL 2.0 pipe type. This is a bug-fix version for bader's patch reviews.llvm.org/D14441 Reviewers: pekka.jaaskelainen, Anastasia Subscribers: bader, Anastasia, cfe-commits Differential Revision: http://reviews.llvm.org/D15603 llvm-svn: 257254
* Only instantiate a default argument once.John McCall2016-01-061-0/+14
| | | | | | | | | | | | | | | | | | | By storing the instantiated expression back in the ParmVarDecl, we remove the last need for separately storing the sub-expression of a CXXDefaultArgExpr. This makes PCH/Modules merging quite simple: CXXDefaultArgExpr records are serialized as references to the ParmVarDecl, and we ignore redundant attempts to overwrite the instantiated expression. This has some extremely marginal impact on user-facing semantics. However, the major effect is that it avoids IRGen errors about conflicting definitions due to lambdas in the argument being instantiated multiple times while sharing the same mangling. It should also slightly improve memory usage and module file size. rdar://23810407 llvm-svn: 256983
* [OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-061-0/+7
| | | | | | | | | | | | 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
* [OpenMP] Revert rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-051-7/+0
| | | | | | | | device codegen. It was causing two regression, so I'm reverting until the cause is found. llvm-svn: 256858
* [OpenMP] Offloading descriptor registration and device codegen.Samuel Antao2016-01-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In order to offloading work properly two things need to be in place: - a descriptor with all the offloading information (device entry functions, and global variable) has to be created by the host and registered in the OpenMP offloading runtime library. - all the device functions need to be emitted for the device and a convention has to be in place so that the runtime library can easily map the host ID of an entry point with the actual function in the device. This patch adds support for these two things. However, only entry functions are being registered given that 'declare target' directive is not yet implemented. About offloading descriptor: The details of the descriptor are explained with more detail in http://goo.gl/L1rnKJ. Basically the descriptor will have fields that specify the number of devices, the pointers to where the device images begin and end (that will be defined by the linker), and also pointers to a the begin and end of table whose entries contain information about a specific entry point. Each entry has the type: ``` struct __tgt_offload_entry{ void *addr; char *name; int64_t size; }; ``` and will be implemented in a pre determined (ELF) section `.omp_offloading.entries` with 1-byte alignment, so that when all the objects are linked, the table is in that section with no padding in between entries (will be like a C array). The code generation ensures that all `__tgt_offload_entry` entries are emitted in the same order for both host and device so that the runtime can have the corresponding entries in both host and device in same index of the table, and efficiently implement the mapping. The resulting descriptor is registered/unregistered with the runtime library using the calls `__tgt_register_lib` and `__tgt_unregister_lib`. The registration is implemented in a high priority global initializer so that the registration happens always before any initializer (that can potentially include target regions) is run. The driver flag -omptargets= was created to specify a comma separated list of devices the user wants to support so that the new functionality can be exercised. Each device is specified with its triple. About target codegen: The target codegen is pretty much straightforward as it reuses completely the logic of the host version for the same target region. The tricky part is to identify the meaningful target regions in the device side. Unlike other programming models, like CUDA, there are no already outlined functions with attributes that mark what should be emitted or not. So, the information on what to emit is passed in the form of metadata in host bc file. This requires a new option to pass the host bc to the device frontend. Then everything is similar to what happens in CUDA: the global declarations emission is intercepted to check to see if it is an "interesting" declaration. The difference is that instead of checking an attribute, the metadata information in checked. Right now, there is only a form of metadata to pass information about the device entry points (target regions). A class `OffloadEntriesInfoManagerTy` was created to manage all the information and queries related with the metadata. The metadata looks like this: ``` !omp_offload.info = !{!0, !1, !2, !3, !4, !5, !6} !0 = !{i32 0, i32 52, i32 77426347, !"_ZN2S12r1Ei", i32 479, i32 13, i32 4} !1 = !{i32 0, i32 52, i32 77426347, !"_ZL7fstatici", i32 461, i32 11, i32 5} !2 = !{i32 0, i32 52, i32 77426347, !"_Z9ftemplateIiET_i", i32 444, i32 11, i32 6} !3 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 99, i32 11, i32 0} !4 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 272, i32 11, i32 3} !5 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 127, i32 11, i32 1} !6 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 159, i32 11, i32 2} ``` The fields in each metadata entry are (in sequence): Entry 1) an ID of the type of metadata - right now only zero is used meaning "OpenMP target region". Entry 2) a unique ID of the device where the input source file that contain the target region lives. Entry 3) a unique ID of the file where the input source file that contain the target region lives. Entry 4) a mangled name of the function that encloses the target region. Entries 5) and 6) line and column number where the target region was found. Entry 7) is the order the entry was emitted. Entry 2) and 3) are required to distinguish files that have the same function name. Entry 4) is required to distinguish different instances of the same declaration (usually templated ones) Entries 5) and 6) are required to distinguish the particular target region in body of the function (it is possible that a given target region is not an entry point - if clause can evaluate always to zero - and therefore we need to identify the "interesting" target regions. ) This patch replaces http://reviews.llvm.org/D12306. Reviewers: ABataev, hfinkel, tra, rjmccall, sfantao Subscribers: FBrygidyn, piotr.rak, Hahnfeld, cfe-commits Differential Revision: http://reviews.llvm.org/D12614 llvm-svn: 256842
* Module file extensions: pass a Sema through to the extension writer.Douglas Gregor2015-12-081-3/+4
| | | | | | | | Module file extensions are likely to need access to Sema/Preprocessor/ASTContext, and cannot get it through other sources. llvm-svn: 255065
* Use range loops and autos in lib/Serialization/ASTWriter.cpp.Eugene Zelenko2015-12-081-127/+103
| | | | | | Differential revision: http://reviews.llvm.org/D15311 llvm-svn: 255033
* [modules] Refactor handling of -fmodules-embed-*. Track this properly ratherRichard Smith2015-11-261-3/+10
| | | | | | | than reusing the "overridden buffer" mechanism. This will allow us to make embedded files and overridden files behave differently in future. llvm-svn: 254121
* Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith2015-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | https://gcc.gnu.org/onlinedocs/gcc/Typeof.html Differences from the GCC extension: * __auto_type is also permitted in C++ (but only in places where it could appear in C), allowing its use in headers that might be shared across C and C++, or used from C++98 * __auto_type can be combined with a declarator, as with C++ auto (for instance, "__auto_type *p") * multiple variables can be declared in a single __auto_type declaration, with the C++ semantics (the deduced type must be the same in each case) This patch also adds a missing restriction on applying typeof to a bit-field, which GCC has historically rejected in C (due to lack of clarity as to whether the operand should be promoted). The same restriction also applies to __auto_type in C (in both GCC and Clang). This also fixes PR25449. Patch by Nicholas Allegra! llvm-svn: 252690
* Moving FileManager::removeDotPaths to llvm::sys::path::remove_dotsMike Aizatsky2015-11-091-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D14394 llvm-svn: 252501
* [Sema] Implement __make_integer_seqDavid Majnemer2015-11-041-0/+2
| | | | | | | | | | | | | | | | | | This new builtin template allows for incredibly fast instantiations of templates like std::integer_sequence. Performance numbers follow: My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz. __make_integer_seq<std::integer_sequence, int, 90000> takes 0.25 seconds. std::make_integer_sequence<int, 90000> takes unbound time, it is still running. Clang is consuming gigabytes of memory. Differential Revision: http://reviews.llvm.org/D13786 llvm-svn: 252036
* Introduce module file extensions to piggy-back data onto module files.Douglas Gregor2015-11-031-4/+54
| | | | | | | | | | | | | | | | | | | | | Introduce the notion of a module file extension, which introduces additional information into a module file at the time it is built that can then be queried when the module file is read. Module file extensions are identified by a block name (which must be unique to the extension) and can write any bitstream records into their own extension block within the module file. When a module file is loaded, any extension blocks are matched up with module file extension readers, that are per-module-file and are given access to the input bitstream. Note that module file extensions can only be introduced by programmatic clients that have access to the CompilerInvocation. There is only one such extension at the moment, which is used for testing the module file extension harness. As a future direction, one could imagine allowing the plugin mechanism to introduce new module file extensions. llvm-svn: 251955
* Eliminate "rewritten decls" from the AST writer. NFCDouglas Gregor2015-11-031-14/+5
| | | | llvm-svn: 251877
* Stop back-patching 'readonly' Objective-C properties with 'readwrite' ones.Douglas Gregor2015-11-031-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A 'readonly' Objective-C property declared in the primary class can effectively be shadowed by a 'readwrite' property declared within an extension of that class, so long as the types and attributes of the two property declarations are compatible. Previously, this functionality was implemented by back-patching the original 'readonly' property to make it 'readwrite', destroying source information and causing some hideously redundant, incorrect code. Simplify the implementation to express how this should actually be modeled: as a separate property declaration in the extension that shadows (via the name lookup rules) the declaration in the primary class. While here, correct some broken Fix-Its, eliminate a pile of redundant code, clean up the ARC migrator's handling of properties declared in extensions, and fix debug info's naming of methods that come from categories. A wonderous side effect of doing this write is that it eliminates the "AddedObjCPropertyInClassExtension" method from the AST mutation listener, which in turn eliminates the last place where we rewrite entire declarations in a chained PCH file or a module file. This change (which fixes rdar://problem/18475765) will allow us to eliminate the rewritten-decls logic from the serialization library, and fixes a crash (rdar://problem/23247794) illustrated by the test/PCH/chain-categories.m example. llvm-svn: 251874
* [modules] Fix merging of __va_list_tag's implicit special member functions.Richard Smith2015-10-131-6/+31
| | | | | | | | | | | We model predefined declarations as not being from AST files, but in most ways they act as if they come from some implicit prebuilt module file imported before all others. Therefore, if we see an update to the predefined 'struct __va_list_tag' declaration (and we've already loaded any modules), it needs a corresponding update record, even though it didn't technically come from an AST file. llvm-svn: 250134
* Serialization: Let ASTWriter return the signature of the written module.Adrian Prantl2015-09-221-15/+22
| | | | | | NFC llvm-svn: 248344
* Support __builtin_ms_va_list.Charles Davis2015-09-171-0/+2
| | | | | | | | | | | | | | | | | | Summary: This change adds support for `__builtin_ms_va_list`, a GCC extension for variadic `ms_abi` functions. The existing `__builtin_va_list` support is inadequate for this because `va_list` is defined differently in the Win64 ABI vs. the System V/AMD64 ABI. Depends on D1622. Reviewers: rsmith, rnk, rjmccall CC: cfe-commits Differential Revision: http://reviews.llvm.org/D1623 llvm-svn: 247941
* EmitRecord* API change: accepts ArrayRef instead of a SmallVector (NFC)Mehdi Amini2015-09-101-180/+125
| | | | | | | | | | | | | | | This reapply a variant commit r247179 after post-commit review from D.Blaikie. Hopefully I got it right this time: lifetime of initializer list ends as with any expression, which make invalid the pattern: ArrayRef<int> Arr = { 1, 2, 3, 4}; Just like StringRef, ArrayRef shouldn't be used to initialize local variable but only as function argument. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247233
* Revert "EmitRecordWith* API change: takes an ArrayRef instead of a ↵Mehdi Amini2015-09-091-122/+180
| | | | | | | | | SmallVector (NFC)" This reverts commit r247179. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247183
* EmitRecordWith* API change: takes an ArrayRef instead of a SmallVector (NFC)Mehdi Amini2015-09-091-180/+122
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247179
* [modules] Write the options records to a separate subblock rather than writingRichard Smith2015-09-081-2/+10
| | | | | | | | them directly to the control block. These are fairly large, and in a build with lots of modules / chained PCH, we don't need to read most of them. No functionality change intended. llvm-svn: 247055
* Re-commit r246497 (and dependent changes r246524 and r246521), reverted inRichard Smith2015-09-011-24/+52
| | | | | | | | | | | | | | | | | | | r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015 rejects-valid. Original commit message: [modules] Rework serialized DeclContext lookup table management. Instead of walking the loaded ModuleFiles looking for lookup tables for the context, store them all in one place, and merge them together if we find we have too many (currently, more than 4). If we do merge, include the merged form in our serialized lookup table, so that downstream readers never need to look at our imports' tables. This gives a huge performance improvement to builds with very large numbers of modules (in some cases, more than a 2x speedup was observed). llvm-svn: 246582
* Reverting r246497 (which requires also reverting r246524 and r246521 to ↵Aaron Ballman2015-09-011-52/+24
| | | | | | | | | | | avoid merge conflicts). It broke the build on MSVC 2015. It also broke an MSVC 2013 bot with testing issues. llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117): error C2065: 'Files': undeclared identifier http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/2917 llvm-svn: 246546
* [modules] When emitting line tables, only emit filenames that are actually ↵Richard Smith2015-09-011-5/+15
| | | | | | referenced by the entries that we emit. llvm-svn: 246534
* Don't use fprintf to emit this diagnostic!Richard Smith2015-09-011-3/+3
| | | | llvm-svn: 246526
* [modules] Add some missing blockinfo records.Richard Smith2015-08-311-2/+31
| | | | llvm-svn: 246504
* [modules] Rework serialized DeclContext lookup table management. Instead ofRichard Smith2015-08-311-24/+52
| | | | | | | | | | | | | walking the loaded ModuleFiles looking for lookup tables for the context, store them all in one place, and merge them together if we find we have too many (currently, more than 4). If we do merge, include the merged form in our serialized lookup table, so that downstream readers never need to look at our imports' tables. This gives a huge performance improvement to builds with very large numbers of modules (in some cases, more than a 2x speedup was observed). llvm-svn: 246497
* [modules] The key to a DeclContext name lookup table is not actually aRichard Smith2015-08-261-44/+17
| | | | | | | | DeclarationName (because all ctor names are considered the same, and so on). Reflect this in the type used as the lookup table key. As a side-effect, remove one copy of the duplicated code used to compute the hash of the key. llvm-svn: 246124
* Make FileManager::getFileSystemOptions consistent with ↵Yaron Keren2015-08-261-2/+2
| | | | | | | | | | CompilerInstance::getFileSystemOpts and CompilerInvocation::getFileSystemOpts by renaming it to getFileSystemOpts, marking the const-returning access method const and adding a non-const version, making the function prototypes identical to CompilerInstance::getFileSystemOpts. llvm-svn: 246026
* [modules] Remove unnecessary deserialization of fully-external ↵Richard Smith2015-08-241-3/+3
| | | | | | HeaderFileInfos for all files we've seen in this compilation. llvm-svn: 245881
* [modules] Stop updating all identifiers when writing a module. This isRichard Smith2015-08-241-16/+18
| | | | | | | unnecessary in C++ modules (where we don't need the identifiers for their Decls) and expensive. llvm-svn: 245821
* [modules] Further simplification and speedup of redeclaration chain loading.Richard Smith2015-08-221-73/+1
| | | | | | | | Instead of eagerly deserializing a list of DeclIDs when we load a module file and doing a binary search to find the redeclarations of a decl, store a list of redeclarations of each chain before the first declaration and load it directly. llvm-svn: 245789
* [modules] Rearrange how redeclaration chains are loaded, to remove a walk overRichard Smith2015-08-221-57/+17
| | | | | | | | | | | | | | | | | | | | | | | | | all modules and reduce the number of declarations we load when loading a redeclaration chain. The new approach is: * when loading the first declaration of an entity within a module file, we first load all declarations of the entity that were imported into that module file, and then load all the other declarations of that entity from that module file and build a suitable decl chain from them * when loading any other declaration of an entity, we first load the first declaration from the same module file As before, we complete redecl chains through name lookup where necessary. To make this work, I also had to change the way that template specializations are stored -- it no longer suffices to track only canonical specializations; we now emit all "first local" declarations when emitting a list of specializations for a template. On one testcase with several thousand imported module files, this reduces the total runtime by 72%. llvm-svn: 245779
* [modules] Fix HeaderFileInfo serialization to store all the known owning ↵Richard Smith2015-08-181-34/+40
| | | | | | modules for a header, not just the current favourite. llvm-svn: 245390
* Range-based-for-convert some loops in ASTWriter. No functionality change ↵Richard Smith2015-08-181-35/+25
| | | | | | intended. llvm-svn: 245361
* [modules] When explicitly building a module file, don't include timestamps inRichard Smith2015-08-171-18/+20
| | | | | | | the produced pcm file for stable file creation across distributed build systems. llvm-svn: 245199
* [modules] When writing a module file built with -fmodule-map-file-home-is-cwd,Richard Smith2015-08-131-9/+18
| | | | | | | | via a module map found by -fmodule-map-file=, the home directory of the module is the current working directory, even if that's a different directory on reload. llvm-svn: 244988
* [modules] Remove now-dead code for lazy loading of files specified by ↵Richard Smith2015-08-091-10/+0
| | | | | | -fmodule-file=. llvm-svn: 244417
* [modules] Stop walking all modules when looking for lexical decls for aRichard Smith2015-08-061-9/+14
| | | | | | DeclContext. These only ever come from the owning module file for the Decl. llvm-svn: 244285
* [modules] Defer setting up the lookup table for a DeclContext until we canRichard Smith2015-08-061-0/+4
| | | | | | | | | | | | | | | | determine the primary context, rather than sometimes registering the lookup table on the wrong context. This exposed a couple of bugs: * the odr violation check didn't deal properly with mergeable declarations if the declaration retained by name lookup wasn't in the canonical definition of the class * the (broken) RewriteDecl mechanism would emit two name lookup tables for the same DeclContext into the same module file (one as part of the rewritten declaration and one as a visible update for the old declaration) These are both fixed too. llvm-svn: 244192
OpenPOWER on IntegriCloud