imposes a constraint that GOT16 referring to a local symbol or HI16 has to be
followed immediately by a matching LO16 relocation.

llvm-svn: 153553

them as machine instructions. Directives ".set noat" and ".set at" are now
emitted only at the beginning and end of a function except in the case where
they are emitted to enclose .cpload with an immediate operand that doesn't fit
in 16-bit field or unaligned load/stores.

Also, make the following changes:
- Remove function isUnalignedLoadStore and use a switch-case statement to
  determine whether an instruction is an unaligned load or store.

- Define helper function CreateMCInst which generates an instance of an MCInst
  from an opcode and a list of operands.

llvm-svn: 153552

any side effects.

llvm-svn: 153551

flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.

Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.

I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.

llvm-svn: 153550

llvm-svn: 153549

completion item. For example, if the code completion itself represents
a declaration in a namespace (say, std::vector), then this API
retrieves the cursor kind and name of the namespace (std). Implements
<rdar://problem/11121951>.

llvm-svn: 153545

necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.

llvm-svn: 153544

llvm-svn: 153543

llvm-svn: 153542

llvm-svn: 153541

llvm-svn: 153540

disables all compiler warnings.

rdar://11059556

llvm-svn: 153539

executable has been moved to another machine). If that's not available
(read-only or something), then exit gracefully.
<rdar://problem/11111686>

llvm-svn: 153538

indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.

lldb_private::Section now has:

bool
Section::IsThreadSpecific () const
{
    return m_thread_specific;
}

void
Section::SetIsThreadSpecific (bool b)
{
    m_thread_specific = b;
}

The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"
sections.

Eventually we need to have each lldb_private::Thread subclass be able to 
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.

llvm-svn: 153537

llvm-svn: 153536

// rdar://11124775

llvm-svn: 153535

The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.

This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.

This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement. 

The option is turned off by default for now.

llvm-svn: 153534

llvm-svn: 153533

Report root function name with exhausted block diagnostic.

Also, use stack frames, not just any location context when checking if
the basic block is in the same context.

llvm-svn: 153532

analyzes.

(This method can be called twice on the same function.)

llvm-svn: 153531

Patch by Jack Carter.

llvm-svn: 153530

will always be tiny sets, so DenseSet is overkill (SmallSet won't work as we
need iteration support). 

llvm-svn: 153529

If EmitNOAT is true, directives ".set noat" and ".set at" are emitted at the
beginning and end of a function. 

llvm-svn: 153528

"#include MACRO(STUFF)".

-As an inclusion position for the included file, use the file location of the file where it
was included but *after* the macro expansions. We want the macro expansions to be considered
as before-in-translation-unit for everything in the included file.

-In the preprocessing record take into account that only inclusion directives can be encountered
as "out-of-order" (by comparing the start of the range which for inclusions is the hash location)
and use binary search if there is an extreme number of macro expansions in the include directive.

Fixes rdar://11111779

llvm-svn: 153527

// rdar://11124354

llvm-svn: 153526

testing a) the wrong behavior or b) something that I'm already testing
in the new test.

llvm-svn: 153525

Fixes PR10105

llvm-svn: 153524

llvm-svn: 153523

list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.

llvm-svn: 153522

undefined behavior, which Rafael was kind enough to fix.

Original commit message for r153423:
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loding a boolean value.

llvm-svn: 153521

This pass tries to update kill flags, but there are still many bugs.
Passes after the load/store optimizer don't need accurate liveness, so
don't even try.

<rdar://problem/11101911>

llvm-svn: 153519

llvm-svn: 153518

Branch folding can use a register scavenger to update liveness
information when required. Don't do that if liveness information is
already invalid.

llvm-svn: 153517

llvm-svn: 153516

same. pr12357.

llvm-svn: 153515

llvm-svn: 153514

llvm-svn: 153513

case that I forgot to check in.

llvm-svn: 153512

Late optimization passes like branch folding and tail duplication can
transform the machine code in a way that makes it expensive to keep the
register liveness information up to date. There is a fuzzy line between
register allocation and late scheduling where the liveness information
degrades.

The MRI::tracksLiveness() flag makes the line clear: While true,
liveness information is accurate, and can be used for register
scavenging. Once the flag is false, liveness information is not
accurate, and can only be used as a hint.

Late passes generally don't need the liveness information, but they will
sometimes use the register scavenger to help update it. The scavenger
enforces strict correctness, and we have to spend a lot of code to
update register liveness that may never be used.

llvm-svn: 153511

llvm-svn: 153508