parts of the accumulators and gets expanded post-RA.

llvm-svn: 192667

a patch by Michael Han.

llvm-svn: 192666

of relying on AddedComplexity.

llvm-svn: 192665

If a class is using the unspecified inheritance model for member
pointers and later we find the class is defined to use single
inheritance, zero out the vbptr offset field of the member pointer when
it is formed.

llvm-svn: 192664

llvm-svn: 192663

llvm-svn: 192662

llvm-svn: 192661

llvm-svn: 192660

When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the
registers on the remote server. When those packets aren't supported, LLDB doesn't
know what the registers look like. This checkin implements a setting that can be used
to specify a python file that contains the registers definitions. The setting is:

(lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py

Inside module there should be a function:

def get_dynamic_setting(target, setting_name):

This dynamic setting function is handed the "target" which is a SBTarget, and the 
"setting_name", which is the name of the dynamic setting to retrieve. For the GDB
remote target definition the setting name is 'gdb-server-target-definition'. The
return value is a dictionary that follows the same format as the OperatingSystem
plugins follow. I have checked in an example file that implements the x86_64 GDB
register set for people to see:

    examples/python/x86_64_target_definition.py
    
This allows LLDB to debug to any archticture that is support and allows users to
define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo)
are not supported by the remote GDB server.

A few benefits of doing this in Python:
1 - The dynamic register context was already supported in the OperatingSystem plug-in
2 - Register contexts can use all of the LLDB enumerations and definitions for things
    like lldb::Format, lldb::Encoding, generic register numbers, invalid registers 
    numbers, etc.
3 - The code that generates the register context can use the program to calculate the
    register context contents (like offsets, register numbers, and more)
4 - True dynamic detection could be used where variables and types could be read from 
    the target program itself in order to determine which registers are available since
    the target is passed into the python function.
    
This is designed to be used instead of XML since it is more dynamic and code flow and
functions can be used to make the dictionary.

llvm-svn: 192646

migration to NS_ENUM/NS_OPTIONS macros; when
typedef'ed to NSInteger/NSUInteger preceeds well
before of the enum declaration. // rdar://15201056

llvm-svn: 192645

that looks like a function declaration, except that it's missing a return type,
try typo-correcting it to the relevant constructor name.

In passing, fix a bug where the missing-type-specifier recovery codepath would
drop a preceding scope specifier on the floor, leading to follow-on diagnostics
and incorrect recovery for the auto-in-c++98 hack.

llvm-svn: 192644

Add has_feature support for reflecting the presence of refined Objective-C ABI mangling for qualified id<...>.  Fixes <rdar://problem/14799110>.

llvm-svn: 192643

llvm-svn: 192642

llvm-svn: 192641

llvm-svn: 192640

Switching some custom logic to using table-generated helper methods.  This also removes an unnecessary diagnostic.

llvm-svn: 192639

llvm-svn: 192638

Thanks to Shuxin Yang for catching this.

llvm-svn: 192637

through bitcast, ptrtoint, and inttoptr instructions. This is valid
only if the related instructions are in that same basic block, otherwise
we may reference variables that were not live accross basic blocks
resulting in undefined virtual registers.

The bug was exposed when both SDISel and FastISel were used within the same
function, i.e., one basic block is issued with FastISel and another with SDISel,
as demonstrated with the testcase.

<rdar://problem/15192473>

llvm-svn: 192636

This pass is needed to break false dependencies. Without it, unlucky
register assignment can result in wild (5x) swings in
performance. This pass was trying to handle AVX but not getting it
right. AVX doesn't have partial register defs, it has unused register
reads in which the high bits of a source operand are copied into the
unused bits of the dest.

Fixing this requires conservative liveness analysis. This is awkard
because the pass already has its own pseudo-liveness. However, proper
liveness is expensive, and we would like to use a generic utility to
compute it. The fix only invokes liveness on-demand. It is rare to
detect a case that needs undef-read dependence breaking, but when it
happens, it can be needed many times within a very large block.

I think the existing heuristic which uses a register window of 16 is
too conservative for loop-carried false dependencies. If the loop is a
reduction. The out-of-order engine may be able to execute several loop
iterations in parallel. However, I'll leave this tuning exercise for
next time.

llvm-svn: 192635

llvm-svn: 192634

llvm-svn: 192633

llvm-svn: 192632

a) x86-64 TLS has been documented
b) the code path should use movq for the correct relocation
   to be generated.

I've also added a fixme for the test case that we should improve
the code generated, it should look something like is documented
in the tls abi document.

llvm-svn: 192631

llvm-svn: 192630

llvm-svn: 192629

Add the capability for LLDB to query an arbitrary Python module (passed in as a file path) for target-specific settings
This is implemented by means of a get_dynamic_setting(target, setting_name) function vended by the Python module, which can respond to arbitrary string names with dynamically constructed
settings objects (most likely, some of those that PythonDataObjects supports) for LLDB to parse

This needs to be hooked up to the debugger via some setting to allow users to specify which module will vend the information they want to supply

llvm-svn: 192628

llvm-svn: 192627

We have to reserve at least the width of a pointer for the vfptr.  For
classes with small alignment, we weren't reserving enough space, and
were overlapping the first field with the vfptr.

llvm-svn: 192626

llvm-svn: 192625

Clobbering is exclusive not inclusive on register units.
For liveness, we need to consider all the preserved registers.
e.g. A regmask that clobbers YMM0 may preserve XMM0.
Units are only clobbered when all super-registers are clobbered.

llvm-svn: 192623

Some clients may add block live ins and may track liveness over a
large scope. This guarantees an efficient implementation in all cases
with no memory allocation/deallocation, independent of the number of
target registers. It could be slightly less convenient but is fine in
the expected case.

llvm-svn: 192622

llvm-svn: 192621

llvm-svn: 192620

llvm-svn: 192619

Clean up creation of static member DIEs. We can create static member DIEs from
two places, so we call getOrCreateStaticMemberDIE from the two places.

getOrCreateStaticMemberDIE will get or create the context DIE first, then it
will check if the DIE already exists, if not, we create the static member DIE
and add it to the context.

Creation of static member DIEs are handled in a similar way as subprogram DIEs.

llvm-svn: 192618

That wasn't confusing /at all/...

llvm-svn: 192617

This patch fixes the distructor test when checking for vtordisp requirements in 
microsoft record layout.  A test case is also included.

Addresses:
http://llvm.org/bugs/show_bug.cgi?id=16406#c7

llvm-svn: 192616

Adjust linkage to make more sense for older releases.

llvm-svn: 192615

llvm-svn: 192614