Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211610 91177308-0d34-0410-b5e6-96231b3b80d8
This looks like the right way for this check to work, but there is
another semi-obvious bug, I would think: why is CurLoc not zero'd out
between functions? The possibility for it to bleed between them seems
problematic. (& indeed I caused tests to fail when I fixed this a
different way, by setting CurLoc to SourceLocation() and the end of
EmitFunctionEnd... )
The changes to debug-info-blocks.m are due to a mismatch between the
source manager's file naming and CGDebugInfo's default handling when no
-main-file-name is specified. This actually reveals somewhat of a bug in
the debug info when using source files from standard in, too. See the
comment in CGDebugInfo::CreateCompileUnit for more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208742 91177308-0d34-0410-b5e6-96231b3b80d8
While constructing ObjC Interface types we might create the declaration
of some normal C++ types, thus adding things to the ReplaceMap. Make
sure we process the ReplaceMap after the ObjC interfaces.
In theory we know at this point, since we're at the end of the TU, that
we won't be upgrading any declarations to definitions, so we could just
construct non-temporary nodes, but that would require extra state in
CGDebugInfo to conditionalize the creation of declaration nodes which
seems annoying/more work than is appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208226 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208114 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking the compiler-rt build. Reverting while I
investigate/fix.
This reverts commit r208065.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208106 91177308-0d34-0410-b5e6-96231b3b80d8
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208065 91177308-0d34-0410-b5e6-96231b3b80d8
CGDebugInfo and DIBuilder were lax in their handling of temporary
MDNodes. All temporary nodes need to be deleted, which means they need
to be RAUW'd with a permanent node. This was not happening.
To ensure this, leverage DIBuilder's new ability to create both
permanent and temporary declarations. Ensure all temporary declarations
are RAUW'd, even with itself. (DIDescriptor::RAUW handles the case where
it is replaced with itself and creates a new, duplicate permanent node
to replace itself with)
This means that all temporary declarations must be added to the
ReplacementMap even if they're never upgraded to definitions - so move
the point of insertion into the map to the point of creation of the
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208055 91177308-0d34-0410-b5e6-96231b3b80d8
This takes a different approach than the
completedType/requiresCompleteType work which relies on AST callbacks to
upgrade the type declaration to a definition. Instead, just defer
constructing the definition to the end of the translation unit.
This works because the definition is never needed by other debug info
(so far as I know), whereas the definition of a struct may be needed by
other debug info before the end of the translation unit (such as
emitting the definition of a member function which must refer to that
member function's declaration).
If we had a callback for whenever an IVar was added to an ObjC interface
we could use that, and remove the need for the ObjCInterfaceCache, which
might be nice. (also would need a callback for when it was more than
just a declaration so we could get properties, etc).
A side benefit is that we also don't need the CompletedTypeCache
anymore. Just rely on the declaration-ness of a type to decide whether
its definition is yet to be emitted.
There's still the PR19562 memory leak, but this should hopefully make
that a bit easier to approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208015 91177308-0d34-0410-b5e6-96231b3b80d8
Items were being redundantly added to the replacement map (both when the
declaration was created, and then again when its definition was
constructed) which caused extra handling to be required when walking the
map (as elements may've already been replaced due to prior entries). By
avoiding adding the duplicates, the checks in the replacement handling
can be replaced with assertions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208000 91177308-0d34-0410-b5e6-96231b3b80d8
parts of Clang. I don't really have any opinion about whether using that
macro is good or bad, but its odd that this is the only one, and Eric
seemed happy with just nuking it for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206806 91177308-0d34-0410-b5e6-96231b3b80d8
specializations collect all arguments and not just the ones from the
class template partial specialization from which this class template
specialization was instantiated. The debug info does not represent the
partial specialization otherwise and so specialized parameters would
go missing.
rdar://problem/16636569.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206430 91177308-0d34-0410-b5e6-96231b3b80d8
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205999 91177308-0d34-0410-b5e6-96231b3b80d8
sure that a debugger can find them when stepping through code,
for example from the included testcase:
12 int test_it() {
13 c = 1;
14 d = 2;
-> 15 a = 4;
16 return (c == 1);
17 }
18
(lldb) p a
(int) $0 = 2
(lldb) p c
(int) $1 = 2
(lldb) p d
(int) $2 = 2
and a, c, d are all part of the file static anonymous union:
static union {
int c;
int d;
union {
int a;
};
struct {
int b;
};
};
Fixes PR19221.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205952 91177308-0d34-0410-b5e6-96231b3b80d8
We already got the type alias correct (though I've included a test case
here) since Clang represents that like any other typedef - but type
alias templates weren't being handled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205691 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted in 205664 and seems to be fixed by 205668... though
that may be more by accident than anything well founded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205669 91177308-0d34-0410-b5e6-96231b3b80d8
While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205668 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205655.
Breaks the compiler-rt build with an assertion failure in LLVM...
reverting while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205664 91177308-0d34-0410-b5e6-96231b3b80d8
See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.
Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205651 91177308-0d34-0410-b5e6-96231b3b80d8
This was committed 4 years ago in 108916 with insufficient testing to
explain why the "getTypeAsWritten" case was appropriate. Experience says
that it isn't - the presence or absence of an explicit instantiation
declaration was causing this code to generate either i<int> or i<int,
int>.
That didn't seem to be a useful distinction, and omitting the template
arguments was destructive to debuggers being able to associate the two
types across translation units or across compilers (GCC, reasonably,
never omitted the arguments).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205447 91177308-0d34-0410-b5e6-96231b3b80d8
We don't want to encourage the code to emit a lexical block for
a function that needs one in order for the line table to change,
we need to grab the line information from the body of the pattern
that we were instantiated from, this code should do that.
Modify the test case to ensure that we're still looking in the
right place for all of the scopes and also that we haven't
created a lexical block where we didn't need one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205368 91177308-0d34-0410-b5e6-96231b3b80d8
instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204874 91177308-0d34-0410-b5e6-96231b3b80d8
location that the next call emitLocation() would default to. Otherwise
setLocation() may wrongly believe that the current source file didn't
change, when in fact it did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204517 91177308-0d34-0410-b5e6-96231b3b80d8
* detect out of line definitions correctly
* detect member function explicit specializations correctly
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202779 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202769 91177308-0d34-0410-b5e6-96231b3b80d8
Diego Novillo