| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This reverts commit r235025. The test isn't passing yet.
llvm-svn: 235027
|
|
|
|
|
|
| |
Fixes assertions in MC when a local label wasn't defined.
llvm-svn: 235025
|
|
|
|
|
|
|
| |
Since adding invokes of llvm.donothing to cleanups, we come here now,
and trivial EH cleanup usage from clang fails to compile.
llvm-svn: 234948
|
|
|
|
|
|
|
| |
This causes badness for GDB which expects to find a definition in any
compile_unit that has an entry for the variable in its pubnames.
llvm-svn: 234915
|
|
|
|
|
|
|
| |
Gut the `DIDescriptor` wrappers around `MDLocalScope` subclasses. Note
that `DILexicalBlock` wraps `MDLexicalBlockBase`, not `MDLexicalBlock`.
llvm-svn: 234850
|
|
|
|
|
|
|
| |
Continue gutting `DIDescriptor` subclasses, turning them into
as-bare-as-possible pointer wrappers.
llvm-svn: 234843
|
|
|
|
|
|
|
|
|
|
| |
Gut all the non-pointer API from the variable wrappers, except an
implicit conversion from `DIGlobalVariable` to `DIDescriptor`. Note
that if you're updating out-of-tree code, `DIVariable` wraps
`MDLocalVariable` (`MDVariable` is a common base class shared with
`MDGlobalVariable`).
llvm-svn: 234840
|
|
|
|
|
|
|
| |
I don't think this API is helping much. Change the callers to call
`MDType::isBlockByrefStruct()` directly.
llvm-svn: 234837
|
|
|
|
|
|
|
| |
Gut a couple more classes in the DIDescriptor hierarchy. Leave behind
an implicit conversion to `DIDescriptor`, the old base class.
llvm-svn: 234836
|
|
|
|
|
|
|
|
| |
This is along the same lines as r234832, but for `DILocation`. Clean
out all accessors from `DILocation`. Any callers should be using
`MDLocation` directly (e.g., via `operator->()`).
llvm-svn: 234835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completely gut `DIExpression`, turning it into a simple wrapper around
`MDExpression *`. There are two bits of magic left:
- It's constructed from `const MDExpression*` but convertible to
`MDExpression*`.
- It's default-constructed to `nullptr`.
Otherwise, it should behave quite like a raw pointer. Once I've done
the same to the rest of the `DIDescriptor` subclasses, I'll come back to
delete them entirely (and update call sites as necessary to deal with
the missing magic).
llvm-svn: 234832
|
|
|
|
|
|
|
|
|
| |
There's only one user of the various `DIObjCProperty::is*Property()`
accessors -- `DwarfUnit::constructTypeDIE()` -- and it's just using the
reverse logic to reconstruct the bitfield. Drop this API and simplify
the only caller.
llvm-svn: 234818
|
|
|
|
|
|
|
|
| |
`DIGlobalVariable::getGlobal()` isn't really helpful, it just does a
`dyn_cast_or_null<>`. Simplify its only user by doing the cast directly
and delete the code.
llvm-svn: 234796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r234717, reapplying r234698 (in spirit).
As described in r234717, the original `Verifier` check had a
use-after-free. Instead of storing pointers to "interesting" debug info
intrinsics whose bit piece expressions should be verified once we have
typerefs, do a second traversal. I've added a testcase to catch the
`llc` crasher.
Original commit message:
Verifier: Check for incompatible bit piece expressions
Convert an assertion into a `Verifier` check. Bit piece expressions
must fit inside the variable, and mustn't be the entire variable.
Catching this in the verifier will help us find bugs sooner, and makes
`DIVariable::getSizeInBits()` dead code.
llvm-svn: 234776
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r234698.
This caused a use-after-free: `QueuedBitPieceExpressions` holds onto
references to `DbgInfoIntrinsic`s and references them past where they're
deleted (this is because the verifier is run as a function pass, and
then `verifyTypeRefs()` is called during `doFinalization()`).
I'll include a reduced crasher for `llc` when I recommit the check.
llvm-svn: 234717
|
|
|
|
|
|
|
|
|
| |
Convert an assertion into a `Verifier` check. Bit piece expressions
must fit inside the variable, and mustn't be the entire variable.
Catching this in the verifier will help us find bugs sooner, and makes
`DIVariable::getSizeInBits()` dead code.
llvm-svn: 234698
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
|
|
|
|
|
|
|
|
|
|
| |
The IPToState table must be emitted after we have generated labels for
all functions in the table. Don't rely on the order of the list of
globals. Instead, utilize WinEHFuncInfo to tell us how many catch
handlers we expect to outline. Once we know we've visited all the catch
handlers, emit the cppxdata.
llvm-svn: 234566
|
|
|
|
|
|
|
|
| |
The lack of a catch object is indicated by a frame escape index of -1.
Fixes PR23137.
llvm-svn: 234346
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r234295 (and r234294 and r234292 before it). I
removed the implicit conversion to `MDTuple*` r234326, so there's no
longer an ambiguity in `operator[]()`.
I think MSVC should accept the original code now...
llvm-svn: 234335
|
|
|
|
|
|
|
| |
This also moves it earlier so that it they are produced before we print
an end symbol for the data section.
llvm-svn: 234315
|
|
|
|
|
|
|
|
| |
I have no idea what MSVC means with its error text here :(.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2310
llvm-svn: 234295
|
|
|
|
|
|
|
|
| |
Still failing:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2309
llvm-svn: 234294
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308
llvm-svn: 234292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace all uses of `DITypedArray<>` with `MDTupleTypedArrayWrapper<>`
and `MDTypeRefArray`. The APIs are completely different, but the
provided functionality is the same: treat an `MDTuple` as if it's an
array of a particular element type.
To simplify this patch a bit, I've temporarily typedef'ed
`DebugNodeArray` to `DIArray` and `MDTypeRefArray` to `DITypeArray`.
I've also temporarily conditionalized the accessors to check for null --
eventually these should be changed to asserts and the callers should
check for null themselves.
There's a tiny accompanying patch to clang.
llvm-svn: 234290
|
|
|
|
|
|
|
|
|
|
| |
Remove special iterators from `DIExpression` in favour of same in
`MDExpression`. There should be no functionality change here.
Note that the APIs are slightly different: `getArg(unsigned)` counts
from 0, not 1, in the `MDExpression` version of the iterator.
llvm-svn: 234285
|
|
|
|
|
|
| |
Same as r234255, but for lib/CodeGen and lib/Target.
llvm-svn: 234258
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove `DIDescriptor::Verify()` and the `Verify()`s from subclasses.
They had already been gutted, and just did an `isa<>` check.
In a couple of cases I've temporarily dropped the check entirely, but
subsequent commits are going to disallow conversions to the
`DIDescriptor`s directly from `MDNode`, so the checks will come back in
another form soon enough.
llvm-svn: 234201
|
|
|
|
|
|
| |
Now all fields in the WinEH xdata have been filled out.
llvm-svn: 234067
|
|
|
|
|
|
|
| |
This add support for catching an exception such that an exception object
available to the catch handler will be initialized by the runtime.
llvm-svn: 234062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a follow-up to r234021, assert that a debug info intrinsic variable's
`MDLocalVariable::getInlinedAt()` always matches the
`MDLocation::getInlinedAt()` of its `!dbg` attachment.
The goal here is to get rid of `MDLocalVariable::getInlinedAt()`
entirely (PR22778), but I'll let these assertions bake for a while
first.
If you have an out-of-tree backend that just broke, you're probably
attaching the wrong `DebugLoc` to a `DBG_VALUE` instruction. The one
you want is the location that was attached to the corresponding
`@llvm.dbg.declare` or `@llvm.dbg.value` call that you started with.
llvm-svn: 234038
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us catch exceptions in simple cases.
N.B. Things that do not work include (but are not limited to):
- Throwing from within a catch handler.
- Catching an object with a named catch parameter.
- 'CatchHigh' is fictitious, we aren't sure of its purpose.
- We aren't entirely efficient with regards to the number of EH states
that we generate.
- IP-to-State tables are sensitive to the order of emission.
llvm-svn: 233767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pervasively use the types provided by the debug info hierarchy rather
than `MDNode` in `LexicalScopes`.
I noticed (again, I guess, based on comments in the implementation?)
that `DILexicalBlockFile::getScope()` returns something different from
`DILexicalBlockFile::getContext()`. I created a local helper for
getting the same logic from `MDLexicalBlockFile` called
`getScopeOfScope()`. I still don't really understand it, but I've added
some FIXMEs and I'll come back to it (I suspect the way we encode these
objects isn't really ideal).
Note that my previous commit r233610 accidentally changed behaviour in
`findLexicalScope()` -- it transitioned from a call to
`DILexicalBlockFile::getScope()` to `MDLexicalBlockFile::getScope()`
(sounds right, doesn't it?) -- so I've fixed that as a drive-by. No
tests failed with my error, so it looks like we're missing some coverage
here... when I come back to understand the logic, I'll see if I can add
some.
Other than the fix to `findLexicalScope()`, no functionality change.
llvm-svn: 233640
|
|
|
|
|
|
|
|
| |
Generate tables in the .xdata section representing what actions to take
when an exception is thrown. This currently fills in state for
cleanups, catch handlers are still unfinished.
llvm-svn: 233636
|
|
|
|
|
|
|
| |
Don't use `DebugLoc::getFnDebugLoc()`, which creates new `MDLocation`s,
in the backend. We just want to grab the subprogram here anyway.
llvm-svn: 233601
|
|
|
|
|
|
| |
Update lib/CodeGen (and lib/Target) to use the new `DebugLoc` API.
llvm-svn: 233582
|
|
|
|
| |
llvm-svn: 233392
|
|
|
|
|
|
|
| |
We used to dyn_cast<Constant> in the recursive call, but cast<> in the
initial one, and there can be non-Constant initial users.
llvm-svn: 233346
|
|
|
|
|
|
|
|
|
|
| |
There is now a canonical symbol at the end of a section that different
passes can request.
This also allows us to assert that we don't switch back to a section whose
end symbol has already been printed.
llvm-svn: 233026
|
|
|
|
| |
llvm-svn: 232998
|
|
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
|
|
|
|
|
|
|
| |
thumb-ness similar to the rest of the Module level asm printing
infrastructure as debug info finalization happens after the function
may be missing.
llvm-svn: 232875
|
|
|
|
|
|
|
| |
Check return of `getDISubprogram()` before using it. A WIP patch makes
`DIDescriptor` accessors more strict (and would crash on this).
llvm-svn: 232838
|
|
|
|
|
|
|
|
|
|
| |
`DL` might be null, so check for that before using accessors. A WIP
patch to make `DIDescriptors` more strict fails otherwise.
As a bonus, I think the logic is easier to follow now (despite the extra
nesting depth).
llvm-svn: 232836
|
|
|
|
|
|
|
|
| |
nullptr so that users get an earlier dereferencing error and
so that we can use it to conditionalize access to MachineFunction
specific data.
llvm-svn: 232820
|
|
|
|
|
|
|
|
| |
We were creating an expression of the form (S+C)-S which is just C.
Patch by Frédéric Riss. I just added the testcase.
llvm-svn: 232549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch code wanting to create temporary labels for a given entity
(function, cu, exception range, etc) had to keep its own counter to have stable
symbol names.
createTempSymbol would still add a suffix to make sure a new symbol was always
returned, but it kept a single counter. Because of that, if we were to use
just createTempSymbol("cu_begin"), the label could change from cu_begin42 to
cu_begin43 because some other code started using temporary labels.
Simplify this by just keeping one counter per prefix and removing the various
specialized counters.
llvm-svn: 232535
|
|
|
|
| |
llvm-svn: 232487
|
|
|
|
|
|
| |
Despite using the same name these are unrelated.
llvm-svn: 232485
|
|
|
|
| |
llvm-svn: 232481
|