llvm-svn: 198934

SymbolLookUp() call back to return a demangled C++ name to
be used as a comment.

For example darwin's otool(1) program the uses the llvm
disassembler now can produce disassembly like:

callq   __ZNK4llvm6Target20createMCDisassemblerERKNS_15MCSubtargetInfoE ## llvm::Target::createMCDisassembler(llvm::MCSubtargetInfo const&) const

Also fix a bug in LLVMDisasmInstruction() that was not flushing
the raw_svector_ostream for the disassembled instruction string
before copying it to the output buffer that was causing truncation
of the output.

rdar://10173828

llvm-svn: 198637

The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI.  It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied.  This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.

This patch adds basic IR support, docs, and verification.  It does not
attempt to implement any lowering or fix any possibly broken transforms.

When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .

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

llvm-svn: 197645

llvm-svn: 195471

llvm-svn: 195173

This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The
transformation aims to take loops like this:

for (int i = 0; i < 3200; i += 5) {
  a[i]     += alpha * b[i];
  a[i + 1] += alpha * b[i + 1];
  a[i + 2] += alpha * b[i + 2];
  a[i + 3] += alpha * b[i + 3];
  a[i + 4] += alpha * b[i + 4];
}

and turn them into this:

for (int i = 0; i < 3200; ++i) {
  a[i] += alpha * b[i];
}

and loops like this:

for (int i = 0; i < 500; ++i) {
  x[3*i] = foo(0);
  x[3*i+1] = foo(0);
  x[3*i+2] = foo(0);
}

and turn them into this:

for (int i = 0; i < 1500; ++i) {
  x[i] = foo(0);
}

There are two motivations for this transformation:

  1. Code-size reduction (especially relevant, obviously, when compiling for
code size).

  2. Providing greater choice to the loop vectorizer (and generic unroller) to
choose the unrolling factor (and a better ability to vectorize). The loop
vectorizer can take vector lengths and register pressure into account when
choosing an unrolling factor, for example, and a pre-unrolled loop limits that
choice. This is especially problematic if the manual unrolling was optimized
for a machine different from the current target.

The current implementation is limited to single basic-block loops only. The
rerolling recognition should work regardless of how the loop iterations are
intermixed within the loop body (subject to dependency and side-effect
constraints), but the significant restriction is that the order of the
instructions in each iteration must be identical. This seems sufficient to
capture all current use cases.

This pass is not currently enabled by default at any optimization level.

llvm-svn: 194939

llvm-svn: 194770

LLVMGetTargetFromName was not yet present in an LLVM release,
so this does not break compatibility.

llvm-svn: 194769

Patch by Michele Scandale!

llvm-svn: 194760

Otherwise it's impossible to use it. Also don't include C++ headers in
a C header.

llvm-svn: 194581

llvm-svn: 194379

This exposes the new calling conventions (WebKit_JS and AnyReg) via the C API by adding them to the enumeration in Core.h.

llvm-svn: 194323

llvm-svn: 194203

llvm-svn: 194146

Original patch by Chris Wailes

llvm-svn: 194143

Also, properly name the functions.

llvm-svn: 194141

Original patch by Chris Wailes

llvm-svn: 194140

Original patch by Chris Wailes

llvm-svn: 194139

Original patch by Chris Wailes

llvm-svn: 194137

Original patch by Chris Wailes

llvm-svn: 194135

Original patch by David Monniaux

llvm-svn: 194074

stack traces by default if you use PrettyStackTraceProgram, so that existing LLVM-based 
tools will continue to get it without any changes.

llvm-svn: 193971

llvm-svn: 193939

When LLVM is embedded in a larger application, it's not OK for LLVM to intercept crashes.  LLVM already has 
the ability to disable this functionality.  This patch exposes it via the C API.

llvm-svn: 193937

linkonce_odr_auto_hide was in incomplete attempt to implement a way
for the linker to hide symbols that are known to be available in every
TU and whose addresses are not relevant for a particular DSO.

It was redundant in that it all its uses are equivalent to
linkonce_odr+unnamed_addr. Unlike those, it has never been connected
to clang or llvm's optimizers, so it was effectively dead.

Given that nothing produces it, this patch just nukes it
(other than the llvm-c enum value).

llvm-svn: 193865

Objective-C data structures.

This is allows tools such as darwin's otool(1) that uses the
LLVM disassembler take a pointer value being loaded by
an instruction and add a comment to what it is being referenced
to make following disassembly of Objective-C programs
more readable.

For example disassembling the Mac OS X TextEdit app one
will see comments like the following:

movq    0x20684(%rip), %rsi ## Objc selector ref: standardUserDefaults
movq    0x21985(%rip), %rdi ## Objc class ref: _OBJC_CLASS_$_NSUserDefaults
movq    0x1d156(%rip), %r14 ## Objc message: +[NSUserDefaults standardUserDefaults]
leaq    0x23615(%rip), %rdx ## Objc cfstring ref: @"SelectLinePanel"
callq   0x10001386c ## Objc message: -[[%rdi super] initWithWindowNibName:]

These diffs also include putting quotes around C strings
in literal pools and uses "symbol address" in the comment
when adding a symbol name to the comment to tell these
types of references apart:

leaq	0x4f(%rip), %rax ## literal pool for: "Hello world"
movq    0x1c3ea(%rip), %rax ## literal pool symbol address: ___stack_chk_guard

Of course the easy changes are in the LLVM disassembler and
the hard work is up to the implementer of the SymbolLookUp()
call back.

rdar://10602439

llvm-svn: 193833

There are two ways one could implement hiding of linkonce_odr symbols in LTO:
* LLVM tells the linker which symbols can be hidden if not used from native
  files.
* The linker tells LLVM which symbols are not used from other object files,
  but will be put in the dso symbol table if present.

GOLD's API is the second option. It was implemented almost 1:1 in llvm by
passing the list down to internalize.

LLVM already had partial support for the first option. It is also very similar
to how ld64 handles hiding these symbols when *not* doing LTO.

This patch then
* removes the APIs for the DSO list.
* marks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN all linkonce_odr unnamed_addr
  global values and other linkonce_odr whose address is not used.
* makes the gold plugin responsible for handling the API mismatch.

llvm-svn: 193800

Patch by Peter Zotov

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

llvm-svn: 193597

llvm-svn: 193404

This reverts commit r193255 and instead creates an lto_bool_t typedef
that points to bool, _Bool, or unsigned char depending on what is
available.  Only recent versions of MSVC provide a stdbool.h header.

Reviewers: rafael.espindola

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

llvm-svn: 193377

FIXME: I don't think it'd be smart.
llvm-svn: 193256

llvm-svn: 193255

llvm-svn: 193253

Pacifies GCC's -Wstrict-prototypes.

llvm-svn: 193249

llvm-svn: 193165

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

llvm-svn: 193149

All of the Core API functions have versions which accept explicit context, in
addition to ones which work on global context. This commit adds functions
which accept explicit context to the Target API for consistency.

Patch by Peter Zotov

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

llvm-svn: 192913

I expose the API with some caveats:

- The C++ API involves a traditional void* opaque pointer for the fatal 
error callback.  The C API doesn’t do this.  I don’t think that the void* 
opaque pointer makes any sense since this is a global callback - there will 
only be one of them.  So if you need to pass some data to your callback, 
just put it in a global variable.

- The bindings will ignore the gen_crash_diag boolean.  I ignore it because 
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I 
couldn’t imagine any use for it.  I made the gut call that it probably 
wasn’t important enough to expose through the C API.

llvm-svn: 192864

The C API currently allows to dump values (LLVMDumpValue), but a similar method for types was not exported.

Patch by Peter Zotov

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

llvm-svn: 192852

Like LLVMDumpModule but returns the string (that needs to be freed
with LLVMDisposeMessage) instead of printing it to stderr.

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

llvm-svn: 192821