Scalar now can make itself signed if needed.

<rdar://problem/13977632>

llvm-svn: 182668

llvm-svn: 182667

This removes a FIXME in CodeGenModule::SetLLVMFunctionAttributesForDefinition.
When a function is declared cold we can now generate the IR attribute in
addition to marking the function to be optimized for size.

I tried adding a separate CHECK in the existing test, but it was
failing.  I suppose CHECK matches one line exactly once?  This would be
a problem if the attributes are listed in a different order, though they
seem to be sorted.

llvm-svn: 182666

llvm-svn: 182665

- Fix for attach by name
- Details for register support
- Punted on i386 details as its status has drifted since this page was originally posted
- Multi-threaded target support is soon to be released on Linux
- Partial back-trace is called out since its a high-profile issue

llvm-svn: 182664

llvm-svn: 182662

llvm-svn: 182661

llvm-svn: 182660

for labels in inline assembly that aren't in the lookup tables.  E.g.,

  __asm {
   a:
   jmp a
  }

rdar://13983623

llvm-svn: 182659

Summary:
Added stack of preprocessor branching directives, and ignore all tokens
inside #if 0 except for preprocessor directives.

Reviewers: klimek, djasper

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D855

llvm-svn: 182658

llvm-svn: 182657

LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases.

Fixes PR16139.

llvm-svn: 182656

In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:

  BBMap[Load] = generateScalarLoad(...);

the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.

The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.

Here are some other possible explanations from Will Dietz <w@wdtz.org>:

The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old])..  Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.

The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.

llvm-svn: 182655

Discussion and rationale at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130520/175698.html

llvm-svn: 182653

Patch by Will Wilson.

llvm-svn: 182651

which takes a first step towards symbolization of disassembled instructions.

llvm-svn: 182650

llvm-svn: 182648

Suffixing #pragma comment(lib) library names with .lib if necessary.  This matches MSVC behavior, as well as allows us to properly link libraries such as the ones provided by the MSDN examples.

llvm-svn: 182647

llvm-svn: 182646

Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).

llvm-svn: 182645

Previously, an invalid instruction like:

	foo     %r1, %r0

would generate the rather odd error message:

....: error: unknown token in expression
	foo     %r1, %r0
		^

We now get the more informative:

....: error: invalid instruction
	foo     %r1, %r0
	^

The same would happen if an address were used where a register was expected.
We now get "invalid operand for instruction" instead.

llvm-svn: 182644

The idea is to make sure that:

(1) "register expected" is restricted to cases where ParseRegister()
    is called and the token obviously isn't a register.

(2) "invalid register" is restricted to cases where a register-like "%..."
    sequence is found, but the "..." makes no sense.

(3) the generic "invalid operand for instruction" is used in cases where
    the wrong register type is used (GPR instead of FPR, etc.).

(4) the new "invalid register pair" is used if the register has the right type,
    but is not a valid register pair.

Testing of (1)-(3) is now restricted to regs-bad.s.  It uses a representative
instruction for each register class to make sure that only registers from
that class are accepted.

(4) is tested by both regs-bad.s (which checks all invalid register pairs)
and insn-bad.s (which tests one invalid pair for each instruction that
requires a pair).

While there, I changed "Number" to "Num" for consistency with the
operand class.

llvm-svn: 182643

llvm-svn: 182642

llvm-svn: 182641

llvm-svn: 182640

as the BinaryOperator, *not* in the block where the IRBuilder is currently
inserting into. Fixes a bug where scalarizePHI would create instructions
that would not dominate all uses.

llvm-svn: 182639

Other than recognizing the attribute, the patch does little else.
It changes the branch probability analyzer so that edges into
blocks postdominated by a cold function are given low weight.

Added analysis and code generation tests.  Added documentation for the
new attribute.

llvm-svn: 182638

We don't want to report initialization-order bugs when a destructor of a global
variable accesses dynamically initialized global from another
(not necessarily initialized) module. We do this by intercepting __cxa_atexit and
registrering our own callback that unpoisons shadow for all dynamically initialized
global variables.

llvm-svn: 182637

There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.

Defines away PR16132.

llvm-svn: 182636

In these builds, the asserts() are completely compiled out of the code
leaving "End" unused. Directly accessing it, should not have a
performance impact, as it is just a data member.

llvm-svn: 182634

llvm-svn: 182632

[modules] If we hit a failure while loading a PCH/module, abort parsing instead of trying to continue in an invalid state.

Also don't let libclang create a PCH with such an error.

Fixes rdar://13953768

llvm-svn: 182629

This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
  contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
  backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
  disassembler. It first builds an atom for each section. It can also
  construct the CFG, and this splits the text atoms into basic blocks.

MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.

In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).

This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.

Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.

llvm-svn: 182628

Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses.

llvm-svn: 182627

llvm-svn: 182626

This is a basic first step towards symbolization of disassembled
instructions. This used to be done using externally provided (C API)
callbacks. This patch introduces:
- the MCSymbolizer class, that mimics the same functions that were used
  in the X86 and ARM disassemblers to symbolize immediate operands and
  to annotate loads based off PC (for things like c string literals).
- the MCExternalSymbolizer class, which implements the old C API.
- the MCRelocationInfo class, which provides a way for targets to
  translate relocations (either object::RelocationRef, or disassembler
  C API VariantKinds) to MCExprs.
- the MCObjectSymbolizer class, which does symbolization using what it
  finds in an object::ObjectFile. This makes simple symbolization (with
  no fancy relocation stuff) work for all object formats!
- x86-64 Mach-O and ELF MCRelocationInfos.
- A basic ARM Mach-O MCRelocationInfo, that provides just enough to
  support the C API VariantKinds.

Most of what works in otool (the only user of the old symbolization API
that I know of) for x86-64 symbolic disassembly (-tvV) works, namely:
- symbol references: call _foo; jmp 15 <_foo+50>
- relocations:       call _foo-_bar; call _foo-4
- __cf?string:       leaq 193(%rip), %rax ## literal pool for "hello"
Stub support is the main missing part (because libObject doesn't know,
among other things, about mach-o indirect symbols).

As for the MCSymbolizer API, instead of relying on the disassemblers
to call the tryAdding* methods, maybe this could be done automagically
using InstrInfo? For instance, even though PC-relative LEAs are used
to get the address of string literals in a typical Mach-O file, a MOV
would be used in an ELF file. And right now, the explicit symbolization
only recognizes PC-relative LEAs. InstrInfo should have already have
most of what is needed to know what to symbolize, so this can
definitely be improved.

I'd also like to remove object::RelocationRef::getValueString (it seems
only used by relocation printing in objdump), as simply printing the
created MCExpr is definitely enough (and cleaner than string concats).

llvm-svn: 182625

building the resulting expression because it invokes a deleted constructor.

llvm-svn: 182624

llvm-svn: 182620

llvm-svn: 182619

[PowerPC] Remove symbolLo/symbolHi instruction operand types

Now that there is no longer any distinction between symbolLo
and symbolHi operands in either printing, encoding, or parsing,
the operand types can be removed in favor of simply using
s16imm.

This completes the patch series to decouple lo/hi operand part
processing from the particular instruction whose operand it is.

No change in code generation expected from this patch.

llvm-svn: 182618