This is a preliminary patch for fast instruction selection on
PowerPC.  Code generation can differ between DAG isel and fast isel.
Existing tests that specify -O0 were written to expect DAG isel.  Make
this explicit by adding -fast-isel=false to the tests.

In some cases specifying -fast-isel=false produces different code even
when there isn't a fast instruction selector specified.  This is
because TM.Options.EnableFastISel = 1 at -O0 whether or not a FastISel
object exists.  Thus disabling fast isel can actually produce less
conservative code.  Because of this, some of the expected code
generation in the -O0 tests needs to be adjusted.

In particular, handling of function arguments is less conservative
with -fast-isel=false (see isOnlyUsedInEntryBlock() in
SelectionDAGBuilder.cpp).  This results in fewer stack accesses and,
in some cases, reduced stack size as uselessly loaded values are no
longer stored back to spill locations in the stack.

No functional change with this patch; test case adjustments only.

llvm-svn: 183939

The test case for this is way too complex to be useful as a lit test,
and I was unable to reduce it.

https://bugs.freedesktop.org/show_bug.cgi?id=65438

llvm-svn: 183937

llvm-svn: 183936

Also don't depend on Program.h including PathV1.h.

llvm-svn: 183935

llvm-svn: 183934

This pass was assuming that if hasAddressTaken() returns false for a
function, the function's only uses are call sites.  That's not true
because there can be references by BlockAddresses too.

Fix the pass to handle this case.  Fix
BlockAddress::replaceUsesOfWithOnConstant() to allow a function's type
to be changed by RAUW'ing the function with a bitcast of the recreated
function.

Patch by Mark Seaborn.

llvm-svn: 183933

Be sure to print out the full file path when dumping breakpoint resolvers for file and line when the full path was specified.

llvm-svn: 183932

llvm-svn: 183931

llvm-svn: 183930

llvm-svn: 183929

llvm-svn: 183928

Backends shouldn't retain any global state. No functionality change.

llvm-svn: 183927

__clear_cache is special. It needs no signature, but is a real function in
compiler_rt or libgcc.

Patch by Andrew Turner.

llvm-svn: 183926

This is in preparation for switching the clang driver over to using LLVM's
Option library.  Richard Smith introduced most of these changes to the clang
driver in r167638.

Reviewers: espindola on IRC

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

llvm-svn: 183925

llvm-svn: 183924

Added some new example code that can grab all functions from any executable, and it will print out the function name, range, return type and argument types.

This example shows someone could iterate over all functions and do something intelligent with them, like create function signatures. Then two different builds could be compared to verify the API hasn't changed.

llvm-svn: 183923

llvm-svn: 183922

llvm-svn: 183921

llvm-svn: 183920

Now PathV1.h is not needed in GraphWriter.h.

llvm-svn: 183919

isFileIncluded() needed to be marked const.

llvm-svn: 183918

File override structures now contain per-source overrides for headers.

For now, modified headers are written to disk when the Migrator is done.
This is only temporary behaviour since we can expect headers to be
changed by migrating multiple source files. The changes need to be
merged after all migrations are complete.

llvm-svn: 183917

llvm-svn: 183916

llvm-svn: 183915

llvm-svn: 183914

llvm-svn: 183913

llvm-svn: 183912

llvm-svn: 183911

A more flexible container for storing overrides is required for headers. Before
a source goes through the transform pipeline, any headers it references will be
in their original state and unaffected by transforms applied to other sources.
Therefore overrides for headers need to be kept separate for each source file.

This patch doesn't introduce support for storing header overrides yet. It only
replaces the existing structure and makes any necessary changes to support it.

llvm-svn: 183910

llvm-svn: 183909

llvm-svn: 183908

llvm-svn: 183907

Execute's Data parameter is now optional, so we won't allocate memory
for it on Windows and we'll close the process handle.

The Unix code should probably do something similar to avoid accumulation
of zombie children that haven't been waited on.

Tested on Linux and Windows.

llvm-svn: 183906

When choosing a default CPU, clang used to pick ARM7TDMI (which has Thumb) even
when the more restrictive armv4 triple was specified. This should fix that.

Patch by Jeroen Hofstee.

llvm-svn: 183905

llvm-svn: 183904

llvm-svn: 183903

llvm-svn: 183902

llvm-svn: 183901

Thanks to Dmitry Shachnev for the patch
See bug #16317

llvm-svn: 183899

llvm-svn: 183898