| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 233053
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we'd deserialize the list of mem-initializers for a constructor when
we deserialized the declaration of the constructor. That could trigger a
significant amount of unnecessary work (pulling in all base classes
recursively, for a start) and was causing problems for the modules buildbot due
to cyclic deserializations. We now deserialize these on demand.
This creates a certain amount of duplication with the handling of
CXXBaseSpecifiers; I'll look into reducing that next.
llvm-svn: 233052
|
|
|
|
|
|
|
|
|
|
| |
* Strength reduce a std::function to a function pointer,
* Factor out checking the AST file magic number,
* Add a brief doc comment to readAStFileSignature
Thanks to Chandler for spotting these oddities.
llvm-svn: 233050
|
|
|
|
| |
llvm-svn: 233007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is at least one 'copyprivate' clause is associated with the single directive, the following code is generated:
```
i32 did_it = 0; \\ for 'copyprivate' clause
if(__kmpc_single(ident_t *, gtid)) {
SingleOpGen();
__kmpc_end_single(ident_t *, gtid);
did_it = 1; \\ for 'copyprivate' clause
}
<copyprivate_list>[0] = &var0;
...
<copyprivate_list>[n] = &varn;
call __kmpc_copyprivate(ident_t *, gtid, <copyprivate_list_size>,
<copyprivate_list>, <copy_func>, did_it);
...
void<copy_func>(void *LHSArg, void *RHSArg) {
Dst = (void * [n])(LHSArg);
Src = (void * [n])(RHSArg);
Dst[0] = Src[0];
... Dst[n] = Src[n];
}
```
All list items from all 'copyprivate' clauses are gathered into single <copyprivate list> (<copyprivate_list_size> is a size in bytes of this list) and <copy_func> is used to propagate values of private or threadprivate variables from the 'single' region to other implicit threads from outer 'parallel' region.
Differential Revision: http://reviews.llvm.org/D8410
llvm-svn: 232932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
llvm-svn: 232928
|
|
|
|
|
|
| |
which was reverted because it was causing LLDB test failures
llvm-svn: 232907
|
|
|
|
| |
llvm-svn: 232905
|
|
|
|
|
|
|
|
|
| |
The linear variable is privatized (similar to 'private') and its
value on current iteration is calculated, similar to the loop
counter variables.
Differential revision: http://reviews.llvm.org/D8375
llvm-svn: 232890
|
|
|
|
|
|
|
|
|
| |
give an exception specification to a declaration that didn't have an exception
specification in any of our imported modules, emit an update record ourselves.
Without this, code importing the current module would not see an exception
specification that we could see and might have relied on.
llvm-svn: 232870
|
|
|
|
|
|
| |
with them.
llvm-svn: 232853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeclContext.
When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.
This unnecessary work was papering over some other bugs:
- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.
- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).
llvm-svn: 232793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
|
|
|
|
|
|
|
|
|
| |
consumers of that module.
Previously, such a file would only be available if the module happened to
actually import something from that module.
llvm-svn: 232583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
namespace to not merge properly.
We have an invariant here: after a declaration reads its canonical declaration,
it can assume the canonical declaration is fully merged. This invariant can be
violated if deserializing some declaration triggers the deserialization of a
later declaration, because that later declaration can in turn deserialize a
redeclaration of that first declaration before it is fully merged.
The anonymous namespace for a namespace gets stored with the first declaration
of that namespace, which may be before its parent namespace, so defer loading
it until after we've finished merging the surrounding namespace.
llvm-svn: 232455
|
|
|
|
|
|
|
|
|
|
|
| |
building its redecl chains, make sure we pull in the redeclarations of those
canonical declarations.
It's pretty difficult to reach a situation where we can find more canonical
declarations of an entity while building its redecl chains; I think the
provided testcase (4 modules and 7 declarations) cannot be reduced further.
llvm-svn: 232411
|
|
|
|
| |
llvm-svn: 232407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a subset of the existing target CPU features or mismatched CPU
names.
While we can't check that the CPU name used to build the module will end
up being able to codegen correctly for the translation unit, we actually
check that the imported features are a subset of the existing features.
While here, rewrite the code to use std::set_difference and have it
diagnose all of the differences found.
Test case added which walks the set relationships and ensures we
diagnose all the right cases and accept the others.
No functional change for implicit modules here, just better diagnostics.
llvm-svn: 232248
|
|
|
|
|
|
| |
Adds additional semantic analysis + generation of helper expressions for proper codegen.
llvm-svn: 232164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers even if they arrived when merging non-system modules.
The idea of this code is that we don't want to warn the user about
macros defined multiple times by their system headers with slightly
different definitions. We should have this behavior if either the
macro comes from a system module, or the definition within the module
comes from a system header. Previously, we would warn on ambiguous
macros being merged when they came from a users modules even though they
only showed up via system headers.
By surviving this we can handle common system header macro differences
like differing 'const' qualification of pointers due to some headers
predating 'const' being valid in C code, even when those systems headers
are pre-built into a system module.
Differential Revision: http://reviews.llvm.org/D8310
llvm-svn: 232149
|
|
|
|
|
|
|
| |
No functionality change, but deeply-importing module files are smaller and
faster now.
llvm-svn: 232140
|
|
|
|
|
|
|
|
|
|
| |
definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).
One-line fix by me; reduced testcase by Daniel Jasper!
llvm-svn: 231950
|
|
|
|
|
|
|
| |
all the existing declarations of a record-like entity with a pointer to its
definition.
llvm-svn: 231901
|
|
|
|
|
|
| |
while we're writing out the identifier table.
llvm-svn: 231890
|
|
|
|
|
|
| |
actually loading a formerly-canonical declaration.
llvm-svn: 231742
|
|
|
|
|
|
|
|
|
| |
specification, update all prior declarations if the new one has an explicit
exception specification and the prior ones don't.
Patch by Vassil Vassilev! Some minor tweaking and test case by me.
llvm-svn: 231738
|
|
|
|
|
|
|
| |
move the operator delete updating into a separate update record so we can cope
with updating another module's destructor's operator delete.
llvm-svn: 231735
|
|
|
|
|
|
|
|
|
|
| |
of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).
No functionality change intended.
llvm-svn: 231538
|
|
|
|
| |
llvm-svn: 231477
|
|
|
|
| |
llvm-svn: 231455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to save out and eagerly load a (potentially huge) table of merged
formerly-canonical declarations when we loaded each module. This was extremely
inefficient in the presence of large amounts of merging, and didn't actually
save any merging lookup work, because we still needed to perform name lookup to
check that our merged declaration lists were complete. This also resulted in a
loss of laziness -- even if we only needed an early declaration of an entity, we
would eagerly pull in all declarations that had been merged into it regardless.
We now store the relevant fragments of the table within the declarations
themselves. In detail:
* The first declaration of each entity within a module stores a list of first
declarations from imported modules that are merged into it.
* Loading that declaration pre-loads those other entities, so that they appear
earlier within the redeclaration chain.
* The name lookup tables list the most recent local lookup result, if there
is one, or all directly-imported lookup results if not.
llvm-svn: 231424
|
|
|
|
|
|
| |
very first step in updating it.
llvm-svn: 230840
|
|
|
|
|
|
| |
imported modules.
llvm-svn: 230834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic classes in the translation unit and check whether each one's key
function is defined when we got to the end of the TU (and when we got to the
end of each module). This is really terrible for modules performance, since it
causes unnecessary deserialization of every dynamic class in every compilation.
We now use a much simpler (and, in a modules build, vastly more efficient)
system: when we see an out-of-line definition of a virtual function, we check
whether that function was in fact its class's key function. (If so, we need to
emit the vtable.)
llvm-svn: 230830
|
|
|
|
|
|
|
|
| |
undeserialized specializations (because we merged an imported declaration of
the same template since we last added one), don't bother reading in the
specializations themselves just so we can write out their IDs again.
llvm-svn: 230805
|
|
|
|
|
|
| |
to date' after it gets updated.
llvm-svn: 230789
|
|
|
|
|
|
| |
happened to query them; only write them out if something new was added.
llvm-svn: 230727
|
|
|
|
|
|
|
| |
a map keyed off the canonical declaration. Don't try to set it if we're loading
some non-canonical merged declaration.
llvm-svn: 230716
|
|
|
|
|
|
|
| |
accumulate the set of specializations rather than overwriting one list
with another.
llvm-svn: 230712
|
|
|
|
| |
llvm-svn: 230454
|
|
|
|
|
|
| |
of writing out an AST file.
llvm-svn: 230428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
This reapplies r230044 with a fixed configure+make build and updated
dependencies and testcase requirements. Over the last iteration this
version adds
- missing target requirements for testcases that specify an x86 triple,
- a missing clangCodeGen.a dependency to libClang.a in the make build.
rdar://problem/19104245
llvm-svn: 230423
|
|
|
|
|
|
| |
constructor.
llvm-svn: 230417
|
|
|
|
|
|
|
| |
This reverts commit r230305.
Off to fix another round of missing dependencies on various platforms.
llvm-svn: 230309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 3.
llvm-svn: 230305
|
|
|
|
|
|
|
| |
results. No-one was ever modifying a lookup result, and it would not be
reasonable to do so.
llvm-svn: 230123
|
|
|
|
|
|
|
| |
invalidate lookup_iterators and lookup_results for some name within a
DeclContext if the lookup results for a *different* name change.
llvm-svn: 230121
|
|
|
|
|
|
|
|
| |
This reverts commit 230099.
The Linux configure+make build variant still needs some work.
llvm-svn: 230103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 2.
llvm-svn: 230089
|
|
|
|
|
|
|
|
| |
This reverts commit r230067.
Investigating another batch of problems found by the bots.
llvm-svn: 230073
|