requiring full control over the various parameters to the std::iterator
concept / trait thing. This is a precursor for adjusting these things to
where you can write a bidirectional iterator wrapping a random access
iterator with custom increment and decrement logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207487 91177308-0d34-0410-b5e6-96231b3b80d8
never actually compared for equality two pointer unions that were equal.
Fortunately, things seem to work. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207468 91177308-0d34-0410-b5e6-96231b3b80d8
Seems at some point the intent was to emit fission ranges_base as unique
per CU but the code today emits ranges_base as the start of the ranges
section for all CUs being compiled and all the ranges_base relative
addresses are relative to that. So removing this dead code and leaving
the status quo until there's a reason to change it (perhaps something's
faster if it has distinct ranges for each CU).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207464 91177308-0d34-0410-b5e6-96231b3b80d8
clang directly from the LLVM test suite! That doesn't work. I've
followed up on the review thread to try and get a viable solution sorted
out, but trying to get the tree clean here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207462 91177308-0d34-0410-b5e6-96231b3b80d8
FrameEntry doesn't need to hold a reference to the section it is
located in. Instead, pass DataExtractor as an argument of parsing
function.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207461 91177308-0d34-0410-b5e6-96231b3b80d8
There is no need to keep the whole contents of .debug_aranges section
in memory when we build address ranges table. Memory optimization that
used to be in this code (precalculate the size of vector of ranges before
filling it) is not really needed - later we will compact and resize this
vector anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207457 91177308-0d34-0410-b5e6-96231b3b80d8
(Clang doesn't warn here because it knows the string is benign - the
assert still checks what it's intended to - though putting the correct
parens does make clang-format format the code a little better)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207456 91177308-0d34-0410-b5e6-96231b3b80d8
Since all 4 ctor calls in DwarfDebug just pass in a trivially
constructed DIE with the right tag type, sink the tag selection down
into the Dwarf*Unit ctors (removing the argument entirely from callers
in DwarfDebug) and initialize the DIE member in DwarfUnit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207448 91177308-0d34-0410-b5e6-96231b3b80d8
When evaluating an assembly expression for a relocation, we want to
stop at MCSymbols that are in the symbol table, even if they are variables.
This is needed since the semantics may require that the relocation use them.
That is not the case when computing the value of a symbol in the symbol table.
There are no relocations in this case and we have to keep going until we hit
a section or find out that the expression doesn't have an assembly time
value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207445 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the subtle constructScopeDIE has been refactored into two
functions - one returning memory to take ownership of, one returning a
pointer to already owning memory - push unique_ptr through more APIs.
I think this completes most of the unique_ptr ownership of DIEs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207442 91177308-0d34-0410-b5e6-96231b3b80d8
While refactoring out constructScopeDIE into two functions I realized we
were emitting DW_AT_object_pointer in the inlined subroutine when we
didn't need to (GCC doesn't, and the abstract subprogram definition has
the information already).
So here's the refactoring and the bug fix. This is one step of
refactoring to remove some subtle memory ownership semantics. It turns
out the original constructScopeDIE returned ownership in its return
value in some cases and not in others. The split into two functions now
separates those two semantics - further cleanup (unique_ptr, etc) will
follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207441 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r207287, reapplying r207286.
I'm hoping that declaring an explicit struct and instantiating
`addBlockEdges()` directly works around the GCC crash from r207286.
This is a lot more boilerplate, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207438 91177308-0d34-0410-b5e6-96231b3b80d8
This commit provides the necessary C/C++ APIs and infastructure to enable fine-
grain progress report and safe suspension points after each pass in the pass
manager.
Clients can provide a callback function to the pass manager to call after each
pass. This can be used in a variety of ways (progress report, dumping of IR
between passes, safe suspension of threads, etc).
The run listener list is maintained in the LLVMContext, which allows a multi-
threaded client to be only informed for it's own thread. This of course assumes
that the client created a LLVMContext for each thread.
This fixes <rdar://problem/16728690>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207430 91177308-0d34-0410-b5e6-96231b3b80d8
It's bad enough that I have to look up 5 different levels of TableGen class
definitions to work out what bits go where in a simple NEON instruction anyway,
without having to keep track of umpteen unused parameters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207420 91177308-0d34-0410-b5e6-96231b3b80d8
