The height on an instruction is the minimum number of cycles from the
instruction is issued to the end of the trace. Heights are computed for
all instructions in and below the trace center block.
The method for computing heights is different from the depth
computation. As we visit instructions in the trace bottom-up, heights of
used instructions are pushed upwards. This way, we avoid scanning long
use lists, looking for uses in the current trace.
At each basic block boundary, a list of live-in registers and their
minimum heights is saved in the trace block info. These live-in lists
are used when restarting depth computations on a trace that
converges with an already computed trace. They will also be used to
accurately compute the critical path length.
llvm-svn: 161138
keep a shared pointer to their disassembler. This
is important for the LLVM-C disassembler because
it needs to lock its parent in order to disassemble
itself.
This means that every interface that returned a
Disassembler* needs to return a DisassemblerSP, so
that the instructions and any external owners share
the same reference count on the object. I changed
all clients to use this shared pointer, which also
plugged a few leaks.
<rdar://problem/12002822>
llvm-svn: 161123
TinyPtrVector. With these, it is sufficiently functional for my more
normal / pedestrian uses.
I've not included some r-value reference stuff here because the value
type for a TinyPtrVector is, necessarily, just a pointer.
I've added tests that cover the basic behavior of these routines, but
they aren't as comprehensive as I'd like. In particular, they don't
really test the iterator semantics as thoroughly as they should. Maybe
some brave soul will feel enterprising and flesh them out. ;]
llvm-svn: 161104
don't explode if the offset we get is zero. This can happen if
you have an empty virtual base class.
While I'm at it, remove an unnecessary block from the IR-generation
of the null-check, mark the eventual GEP as inbounds, and generally
prettify.
llvm-svn: 161100
Since the llvm::sys::fs::map_file_pages() support function it relies on
is not yet implemented on Windows, the unit tests for FileOutputBuffer
are currently conditionalized to run only on unix.
llvm-svn: 161099
No new test case is added.
This patch makes test JITTest.FunctionIsRecompiledAndRelinked pass on mips
platform.
Patch by Petar Jovanovic.
llvm-svn: 161098
instructions that decrement and increment the stack pointer before and after a
call when the function does not have a reserved call frame.
llvm-svn: 161093
Added new API to lldb::SBTypeMember for bitfields:
bool SBTypeMember::IsBitfield();
uint32_t SBTypeMember::GetBitfieldSizeInBits();
Also added new properties for easy access. Now SBTypeMember objects in python have a "fields" property for all type fields, "bases" for all direct bases, "vbases" for all virtual base classes and "members" for a combo of all three organized by bit offset. They all return a python list() of SBTypeMember objects. Usage:
(lldb) script
>>> t = lldb.target.FindFirstType("my_type")
>>> for field in t.fields:
... print field
>>> for vbase in t.vbases:
... print vbase
>>> for base in t.bases:
... print base
>>> for member in t.members:
... print member
Also added new "is_bitfield" property to the SBTypeMember objects that will return the result of SBTypeMember::IsBitfield(), and "bitfield_bit_size" which will return the result of SBTypeMember::GetBitfieldSizeInBits();
I also fixed "SBTypeMember::GetOffsetInBytes()" to return the correct byte offset.
llvm-svn: 161091
MipsSEFrameLowering.
Implement MipsSEFrameLowering::hasReservedCallFrame. Call frames will not be
reserved if there is a call with a large call frame or there are variable sized
objects on the stack.
llvm-svn: 161090
instructions, be sure to allocate new UnwindPlan::Row's each
time we push a row on to the UnwindPlan so we don't mutate
it any further.
(fallout from changing the UnwindPlan from having a vector
of Row's to having a vector of RowSP shared pointers.)
<rdar://problem/11997385>
llvm-svn: 161089
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
Dmitri Gribenko