This broke in r144788 when the CodeGenOpt option was moved from everywhere else
(specifically, from addPassesToEmitFile) to createTargetMachine. Since
LTOCodeGenerator wasn't passing the 4th argument, when the 4th parameter became
the 3rd, it silently continued to compile (int->bool conversion) but meant
something completely different.

This change preserves the existing (accidental) and previous (default)
semantics of the addPassesToEmitFile and restores the previous/intended
CodeGenOpt argument by passing it appropriately to createTargetMachine.

(discovered by pending changes to -Wconversion to catch constant->bool
conversions)

llvm-svn: 157705

Besides adding the new insertPass function, this patch uses it to
enhance the existing -print-machineinstrs so that the MachineInstrs
after a specific pass can be printed.

Patch by Bin Zeng!

llvm-svn: 157655

llvm-svn: 157612

Found by valgrind.

llvm-svn: 157160

llvm-svn: 157118

llvm-svn: 157112

Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.

Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.

data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"

The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.

rdar://11459456

llvm-svn: 157062

containing no symbols.  Fixed the crash and fixed it not disassembling anything.

llvm-svn: 157031

Added LLIMCJITMemoryManager to the lli. This manager will be used for MCJIT instead of DefaultJIMMemoryManager.
It's more flexible for MCJIT tasks, in addition it's provides a invalidation instruction cache for code sections which will be used before JIT code will be executed.

llvm-svn: 156933

options, to enable easier testing of the innards of LLVM that are
enabled by such optimization strategies.

Note that this doesn't provide the (much needed) function attribute
support for -Oz (as opposed to -Os), but still seems like a positive
step to better test the logic that Clang currently relies on.

Patch by Patrik Hägglund.

llvm-svn: 156913

 - Hopefully fixes PR11600 (untested).

llvm-svn: 156865

that has more than one symbol.  The last symbol was not being disassembled to
the end of the section.

llvm-svn: 156840

 - These libraries are only reported by llvm-config when run from a development
   tree.

llvm-svn: 156838

Add the MCRegisterInfo to the factories and constructors.

Patch by Tom Stellard <Tom.Stellard@amd.com>.

llvm-svn: 156828

llvm-svn: 156606

My previous change to install llvm-config-host for cross-builds resulted
in that file being installed even when the normal llvm-config was not
installed, e.g., when building the install-clang target.  Daniel suggested
this alternative, which solves the immediate problem and also avoids the gunk
in the top-level makefile.

llvm-svn: 156448

PR12731.  Patch by Meador Inge!

llvm-svn: 156444

and expose it as a utility class rather than as free function wrappers.

The simple free-function interface works well for the bugpoint-specific
pass's uses of code extraction, but in an upcoming patch for more
advanced code extraction, they simply don't expose a rich enough
interface. I need to expose various stages of the process of doing the
code extraction and query information to decide whether or not to
actually complete the extraction or give up.

Rather than build up a new predicate model and pass that into these
functions, just take the class that was actually implementing the
functions and lift it up into a proper interface that can be used to
perform code extraction. The interface is cleaned up and re-documented
to work better in a header. It also is now setup to accept the blocks to
be extracted in the constructor rather than in a method.

In passing this essentially reverts my previous commit here exposing
a block-level query for eligibility of extraction. That is no longer
necessary with the more rich interface as clients can query the
extraction object for eligibility directly. This will reduce the number
of walks of the input basic block sequence by quite a bit which is
useful if this enters the normal optimization pipeline.

llvm-svn: 156163

Patch by Meador Inge.

llvm-svn: 156128

llvm-svn: 155978

if !ForceInterpreteri). It has no effect (apart from a memory leak...)

llvm-svn: 155792

llvm-svn: 155669

While making lld build under the tools directory I decided to refactor how this
works.

There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.

 * LLVM_EXTERNAL_${NAME}_SOURCE_DIR
     This is the path to the source. It defaults to
     ${CMAKE_CURRENT_SOURCE_DIR}/${name}.
 * LLVM_EXTERNAL_${NAME}_BUILD
     Enable and disable building the tool as part of LLVM.

I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.

llvm-svn: 155654

llvm-svn: 155536

llvm-ld is no longer useful and causes confusion and so it is being removed.

* Does not work very well on Windows because it must call a gcc like driver to
  assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
  ld, or fully replaced by Clang.

I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.

llvm-svn: 155147

backend flags in TargetOptions.h into their own class in r145714.

llvm-svn: 154993

llvm-svn: 154959

Add -disassemble support for -show-inst and -show-encode capability llvm-mc. Also refactor so all MC paraphernalia are created once for all uses as much as possible. 

The test change is to account for the fact that the default disassembler behaviour has changed with regards to specifying the assembly syntax to use.

llvm-svn: 154809

so we don't want it to show up in the stable 3.1 interface.

While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.

llvm-svn: 154807

Make member variables of AsmToken private. Remove unnecessary forward declarations. Remove an unnecessary include.

llvm-svn: 154775

Patch by nobled <nobled@dreamwidth.org>

llvm-svn: 154772

Thanks to Pino Toscano for the patch

llvm-svn: 154500

ConstantFP::get(Type*, double) is unreliably host-specific:
it can't handle a type like PPC128 on an x86 host. It even
has a comment to that effect: "This should only be used for
simple constant values like 2.0/1.0 etc, that are
known-valid both as host double and as the target format."

Instead, use APFloat. While we're at it, randomize the floating
point value more thoroughly; it was previously limited
to the range 0 to 2**19 - 1.

PR12451.

llvm-svn: 154446

LangRef.html says:
"There are no arrays, vectors or constants of this type."

This was hitting assertions when passing the -generate-x86-mmx
option.

PR12452.

llvm-svn: 154445

Revert the 'EnableInitializing' flag. There is debate on whether we should run that pass by default in LTO.

llvm-svn: 154356

Apply the scope restrictions after parsing the command line options. There may be some which are used in that function.

llvm-svn: 154348

llvm-svn: 154312

llvm-svn: 154306

optimizations which are valid for position independent code being linked
into a single executable, but not for such code being linked into
a shared library.

I discussed the design of this with Eric Christopher, and the decision
was to support an optional bit rather than a completely separate
relocation model. Fundamentally, this is still PIC relocation, its just
that certain optimizations are only valid under a PIC relocation model
when the resulting code won't be in a shared library. The simplest path
to here is to expose a single bit option in the TargetOptions. If folks
have different/better designs, I'm all ears. =]

I've included the first optimization based upon this: changing TLS
models to the *Exec models when PIE is enabled. This is the LLVM
component of PR12380 and is all of the hard work.

llvm-svn: 154294

Consider the following program:

$ cat main.c
void foo(void) { }

int main(int argc, char *argv[]) {
    foo();
    return 0;
}
$ cat bundle.c 
extern void foo(void);

void bar(void) {
     foo();
}
$ clang -o main main.c
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
$ nm -m bundle.so
0000000000000f40 (__TEXT,__text) external _bar
                 (undefined) external _foo (from executable)
                 (undefined) external dyld_stub_binder (from libSystem)
$ clang -o main main.c -O4
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
Undefined symbols for architecture x86_64:
  "_foo", referenced from:
      _bar in bundle-elQN6d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The linker was told that the 'foo' in 'main' was 'internal' and had no uses, so
it was dead stripped.

Another situation is something like:

define void @foo() {
  ret void
}

define void @bar() {
  call asm volatile "call _foo" ...
  ret void
}

The only use of 'foo' is inside of an inline ASM call. Since we don't look
inside those for uses of functions, we don't specify this as a "use."

Get around this by not invoking the 'internalize' pass by default. This is an
admitted hack for LTO correctness.
<rdar://problem/11185386>

llvm-svn: 154124