| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 205999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 205952
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 205691
|
|
|
|
|
|
|
| |
The Decl field in a DIImportedEntity is now a DIRef.
Paired commit with LLVM.
llvm-svn: 205278
|
|
|
|
|
|
| |
in LLVM r203046.
llvm-svn: 203047
|
|
|
|
|
|
| |
in LLVM r203038.
llvm-svn: 203039
|
|
|
|
|
|
| |
r202821.
llvm-svn: 202822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
class and use it pervasively to restore debug locations.
Fixes an interaction between cleanup and EH that caused the location
to not be restored properly after emitting a landing pad.
rdar://problem/15208190
llvm-svn: 199444
|
|
|
|
|
|
|
|
| |
within"
This reverts commit r198461.
llvm-svn: 198714
|
|
|
|
|
|
| |
This reverts commit 198699 so we can get a cleaner patch.
llvm-svn: 198713
|
|
|
|
|
|
|
|
|
| |
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
rdar://problem/15010825
llvm-svn: 198699
|
|
|
|
|
|
|
|
|
| |
the lexical block formed by the compound statement that is the function
body.
rdar://problem/15010825
llvm-svn: 198461
|
|
|
|
|
|
|
|
|
| |
GCC ToT doesn't do this & it's worth about 3.2% on Clang's DWO file size
with Clang. Some or all of this may be due to things like r190715 which
could have source fixes/improvements, but it's not clear that's the case
and that doesn't help other source bases.
llvm-svn: 190716
|
|
|
|
|
|
| |
change.
llvm-svn: 190314
|
|
|
|
|
|
| |
Noticed by Roman Divacky.
llvm-svn: 190311
|
|
|
|
|
|
| |
Improve readability. No functionality change.
llvm-svn: 190268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and tested (in r189996)
Debug info emission was tripping over an IRGen bug (fixed in r189996)
that was resulting in duplicate emission of static data members of class
templates in namespaces.
We could add more test coverage to debug info for this issue
specifically, but I think the underlying IRGen test is more targeted and
sufficient for the issue.
llvm-svn: 190001
|
|
|
|
|
|
|
|
|
|
|
| |
we have a more principled approach (the 'requires complete type' callback)"
This reverts commit r189013.
This is causing a segfault crash in a test case I have. Reverting while
I investigate the issue.
llvm-svn: 189906
|
|
|
|
| |
llvm-svn: 189660
|
|
|
|
|
|
|
| |
The patch was discussed in Phabricator. See:
http://llvm-reviews.chandlerc.com/D1281
llvm-svn: 189649
|
|
|
|
|
|
|
|
|
|
| |
Both functions will take a Type pointer instead of a Decl pointer. This helps
with follow-up type uniquing patches, which need the Type pointer to call
CXX mangler to generate unique identifiers.
No functionality change.
llvm-svn: 189519
|
|
|
|
|
|
|
|
| |
more principled approach (the 'requires complete type' callback)
No functionality change intended.
llvm-svn: 189013
|
|
|
|
| |
llvm-svn: 188834
|
|
|
|
|
|
|
|
|
| |
and definition
Based on code review feedback from Eric Christopher (on r188739) and
Adrian Prantl (r188642).
llvm-svn: 188829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classes in TUs that do not have the vtable for that class""""
This reverts commit r188687 (reverts r188642 (reverts 188600 (reverts
188576))).
With added test coverage & fix for -gline-tables-only.
Thanks Michael Gottesman for reverting this patch when it demonstrated
problems & providing a reproduction/details to help me track this down.
llvm-svn: 188739
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TUs that do not have the vtable for that class"""
This reverts commit r188642.
This change is causing LTO builds to cause our 16 GB machines to swap and OOM
all weekend. I am going to work with Dave Blaikie to resolve the issue.
Sorry Dave =(.
llvm-svn: 188687
|
|
|
|
|
|
|
|
|
|
|
|
| |
do not have the vtable for that class""
This reverts commit r188600.
r188640/r188639 fixed the root cause of the crash-on-valid that r188600
originally introduced. This now appears to bootstrap debug clang
successfully to the best of my testing.
llvm-svn: 188642
|
|
|
|
|
|
|
|
|
| |
Possible minor reduction in debug info & avoid some cases where creating
a context chain could lead to the type the context chain is being
created for, being created. (this is still possible with template
parameters - tests/fixes/improvements to follow)
llvm-svn: 188639
|
|
|
|
|
|
|
|
|
|
| |
have the vtable for that class"
This reverts commit r188576.
Reverting while I investigate a selfhosting buildbot failure on Darwin.
llvm-svn: 188600
|
|
|
|
|
|
|
|
|
| |
vtable for that class
This reduces Clang's .dwo (fission debug info) size by 23% over
Clang+LLVM.
llvm-svn: 188576
|
|
|
|
|
|
|
| |
This is the correct type (as is demonstrated by the fact that the caller
didn't need to change) & will be useful in a future patch.
llvm-svn: 188575
|
|
|
|
|
|
| |
This change broke release+asserts build with compiler-rt.
llvm-svn: 188539
|
|
|
|
|
|
| |
result.
llvm-svn: 188501
|
|
|
|
|
|
| |
for future use
llvm-svn: 188498
|
|
|
|
|
|
|
|
|
| |
match the semantics
Rather than having a cast immediately inside the function, push that
type requirement out to the callers.
llvm-svn: 188492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than going through the whole getOrCreateType machinery to
manifest a type, cut straight to the implementation because we know we
have to do work.
While the previous implementation was sufficient for the two cases
(completeness and required completeness) we have already (the general
machinery could inspect the type for those attributes & go down the full
definition path), a pending change (to emit info for types when we emit
their vtables) won't have that luxury & we'll need to force the creation
rather than relying on the general purpose routine.
llvm-svn: 188486
|
|
|
|
|
|
|
| |
It still does only return DICompositeType, but I've no need to make that
change right now.
llvm-svn: 188482
|
|
|
|
|
|
|
| |
No functionality change, at best a slight (questionable) optimization,
but necessary for correctness of future work.
llvm-svn: 188474
|
|
|
|
| |
llvm-svn: 188214
|
|
|
|
| |
llvm-svn: 187089
|
|
|
|
|
|
| |
of an artificial function gets an artificial location as well.
llvm-svn: 187074
|
|
|
|
| |
llvm-svn: 186557
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inspired by CodegenFunction::LexicalScope.
- NoLocation temporarily turns off debug locations altogether.
This is useful for emitting instructions that should be
counted towards the function prologue.
- BuiltinLocation temporarily switches to an artificial debug location
that has a valid scope, but no line information. This is useful when
emitting compiler-generated helper functions that have no source
location associated with them.
llvm-svn: 186552
|
|
|
|
| |
llvm-svn: 186294
|
|
|
|
|
|
|
| |
BlockLiteralGenericSet and replace with a call to isType() on the
BlockLiteralGeneric.
llvm-svn: 186293
|
|
|
|
|
|
| |
and parameter packs
llvm-svn: 184644
|
|
|
|
| |
llvm-svn: 184512
|
|
|
|
|
|
|
|
|
|
|
| |
This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.
No intended functionality change.
llvm-svn: 184509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used via typedefs
In an effort to make -flimit-debug-info more consistent I over-shot the
mark & made types used via typedefs never produce definitions in the
debug info (even if the type was used in a way that would require a
definition).
The fix for this is to do exactly what I was hoping to do at some point
- plumb the declaration/definition choice through the various layers of
"CreateType" in CGDebugInfo. In this way we can produce declarations
whenever they are sufficient & definitions otherwise - including when
qualifiers are used, for example (discovered in PR14467). This may not
be complete (there may be other types/situations where we need to
propagate the "declaration/definition" choice) but it lays the basic
foundation which we can enhance in future iterations.
llvm-svn: 183296
|