Summary:
These preambles are built by ASTUnit and clangd. Previously, preambles
were always stored on disk.
In-memory preambles are routed back to the compiler as virtual files in
a custom VFS.
Interface of ASTUnit does not allow to use in-memory preambles, as
ASTUnit::CodeComplete receives FileManager as a parameter, so we can't
change VFS used by the compiler inside the CodeComplete method.
A follow-up commit will update clangd in clang-tools-extra to use
in-memory preambles.
Reviewers: klimek, sammccall, bkramer
Reviewed By: klimek
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D39842
llvm-svn: 318411
A first step toward removing the repetition of
features/CPU info in the x86 target info, this
patch pulls all the processor information out into
its own .def file.
Differential Revision: https://reviews.llvm.org/D40093
llvm-svn: 318343
In the PR, Clang ended up in a situation where it tried to mangle the
__float128 type, which isn't supported when targetingt MSVC, because
Clang instantiated a variable template with that type when searching for
a conversion to use in an arithmetic expression.
Differential revision: https://reviews.llvm.org/D39579
llvm-svn: 318309
Internal linkage variables ODR referenced from inline functions create
ODR violations (the same inline function ends up having different
definitions in each TU, since it references different variables - rather
than one definition).
This also happens to break modular code generation - so this is the last
fix to allow clang to compile with modular code generation.
llvm-svn: 318304
Summary:
Constant samplers are handled as static variables and clang's code generation
library, which leads to llvm::unreachable. We bypass emitting sampler variable
as static since it's translated to a function call later.
Reviewers: yaxunl, Anastasia
Reviewed By: yaxunl, Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34342
llvm-svn: 318290
When we merge together class definitions, we can end up with the canonical
declaration of a field not being the one that was lexically within the
canonical definition of the class. Additionally, when we merge class
definitions via update records (eg, for a template specialization whose
declaration is instantiated in one module and whose definition is instantiated
in multiple others), we can end up with the list of lexical contents for the
class not including a particular declaration of a field whose lexical parent is
that class definition. In the worst case, we have a field whose canonical
declaration's lexical parent has no fields, and in that case this attempt to
number the fields by walking the fields in the declaration of the class that
contained one of the canonical fields will fail.
Instead, when numbering fields in a class, do the obvious thing: walk the
fields in the definition.
I'm still trying to reduce a testcase; the setup that leads to the above
scenario seems to be quite fragile.
llvm-svn: 318245
LLVM exposes a file in the backend (X86TargetParser.def) that
contains information about the correct list of CpuIs values.
This patch removes 2 of the copied and pasted versions of this
list from clang and instead includes the data from the .def file.
Differential Revision: https://reviews.llvm.org/D40054
llvm-svn: 318234
Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions. There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.
This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:
Loop Nesting Example
--------------------
// Snippet 1
while (foo()) {
while (bar()) {}
}
// Snippet 2
while (foo()) {}
while (bar()) {}
Condition Example
-----------------
// Snippet 1
if (foo())
bar();
baz();
// Snippet 2
if (foo())
bar();
else
baz();
Out-of-order Control Flow Example
---------------------------------
// Snippet 1
while (foo()) {
if (bar()) {}
baz();
}
// Snippet 2
while (foo()) {
if (bar())
continue;
baz();
}
In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.
The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:
// Snippet 1
bool c = !a || b;
if (d && e) {}
// Snippet 2
bool f = d && e;
bool c = !a || b;
if (f) {}
This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.
Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).
rdar://17068282
Differential Revision: https://reviews.llvm.org/D39446
llvm-svn: 318229
On e.g. PPC the return value and argument were marked 'signext'. This
makes the test expectations a bit more flexible.
Follow-up to r318199.
llvm-svn: 318214
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
Summary:
Allow the `isDefinition()` matcher to apply to `ObjCMethodDecl` nodes, in
addition to those it already supports. For whatever reason, `ObjCMethodDecl`
does not inherit from `FunctionDecl` and so this is specialization is necessary.
Reviewers: aaron.ballman, malcolm.parsons, alexshap
Reviewed By: aaron.ballman
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39948
llvm-svn: 318152
Enabled crash recovery for some libclang operations on a calling thread even
when LIBCLANG_NOTHREAD is specified.
Previously it would only run under crash recovery if LIBCLANG_NOTHREAD is not
set. Moved handling of LIBCLANG_NOTHREAD env variable into RunSafely from its
call sites.
llvm-svn: 318142
Create more orthogonal pieces. The restructuring made it easy to try out
several alternatives to D33589, and while none of the alternatives
turned out to be the right solution, the underlying simplification of
the structure is helpful.
Differential Revision: https://reviews.llvm.org/D39900
llvm-svn: 318141
Summary: Currently the -fdebug-pass-manager flag for clang doesn't enable the debug logging in the analysis managers. This is different than what the switch does when passed to opt.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40007
llvm-svn: 318140
Not much interesting here. Mostly wiring things together.
One thing worth noting is that the approach is substantially different
from the old PM. Here, the -O0 case works fundamentally differently in
that we just directly build the pipeline without any callbacks or other
cruft. In some ways, this is nice and clean. However, I don't like that
it causes the sanitizers to be enabled with different changes at
different times. =/ Suggestions for a better way to do this are welcome.
Differential Revision: https://reviews.llvm.org/D39085
llvm-svn: 318131
Registers it and everything, updates all the references, etc.
Next patch will add support to Clang's `-fexperimental-new-pass-manager`
path to actually enable BoundsChecking correctly.
Differential Revision: https://reviews.llvm.org/D39084
llvm-svn: 318128
This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.
llvm-svn: 318112
cbrt() is always constant because it can't overflow or underflow. Therefore, it can't set errno.
fma() is not always constant because it can overflow or underflow. Therefore, it can set errno.
But we know that it never sets errno on GNU / MSVC, so make it constant in those environments.
Differential Revision: https://reviews.llvm.org/D39641
llvm-svn: 318093
The ObjCGenerics checker warns on a cast when there is no subtyping relationship
between the tracked type of the value and the destination type of the cast. It
does this even if the cast was explicitly written. This means the user can't
write an explicit cast to silence the diagnostic.
This commit treats explicit casts involving generic types as an indication from
the programmer that the Objective-C type system is not rich enough to express
the needed invariant. On explicit casts, the checker now removes any existing
information inferred about the type arguments. Further, it no longer assumes
the casted-to specialized type because the invariant the programmer specifies
in the cast may only hold at a particular program point and not later ones. This
prevents a suppressing cast from requiring a cascade of casts down the
line.
rdar://problem/33603303
Differential Revision: https://reviews.llvm.org/D39711
llvm-svn: 318054
Yaxun Liu