Comes in two parts:
 1. Use --with-clang=path/to/clang/compiler to select an installed clang, or
    --with-built-clang to have the makefiles use the clang which will be built
    as the LLVM capable compiler. If neither is given, --with-built-clang will
    be used if the Clang sources are checked out into the standard location
    (tools/clang).

 2. Use --with-llvmcc={llvm-gcc,clang,none} to specify which LLVM capable
    compiler to use. If not given, then llvm-gcc will be used if available,
    otherwise Clang.

Makefile support still to come.

Eric, Doug, Chris, seem reasonable?

llvm-svn: 96934

llvm-svn: 96933

llvm-svn: 96932

llvm-svn: 96931

llvm-svn: 96927

llvm-svn: 96926

They are giving us problems on Mac.

llvm-svn: 96925

llvm-svn: 96924

llvm-svn: 96923

Needed to correctly handle things like 'llvmc -framework Foo foo.o -framework
Bar bar.o' - before this commit all '-framework' options would've been grouped
together in the beginning.

Due to our dependence on CommandLine this turned out to be a giant hack; we will
migrate away from CommandLine eventually.

llvm-svn: 96922

llvm-svn: 96921

Does not work, but the infrastructure changes are in place.

llvm-svn: 96920

llvm-svn: 96919

For now, just enough support to make -filelist work.

llvm-svn: 96918

llvm-svn: 96917

llvm-svn: 96916

llvm-svn: 96913

llvm-svn: 96912

llvm-svn: 96911

llvm-svn: 96910

llvm-svn: 96909

llvm-svn: 96908

llvm-svn: 96907

llvm-svn: 96906

input/output patterns have the same type.  It turns out that 
this triggers all the time because we don't infer types 
between these boundaries.  Until we do, don't turn this on.

llvm-svn: 96905

of a pattern and where the uses have different types.

llvm-svn: 96904

llvm-svn: 96903

in the recent changes to RegionStore::InvalidateRegions().  Note that we
are still not yet modeling 'memcpy()' explicitly.

llvm-svn: 96902

then use it as an MMX register (!?).

llvm-svn: 96901

this is tidier and can find bugs.

llvm-svn: 96900

though some look dubious afaict, these are all ok.

llvm-svn: 96899

but not in the input.  Previously, this would trigger an abort
late in the isel logic.

llvm-svn: 96898

llvm-svn: 96897

llvm-svn: 96896

the canonical calling conventions instead of comparing the raw calling
conventions directly. Fixes PR6361.

llvm-svn: 96895

place where an i32 imm was required, the old isel just got lucky.

This fixes CodeGen/X86/x86-64-and-mask.ll

llvm-svn: 96894

to libAnalysis (with only the error reporting in libSema).

llvm-svn: 96893

llvm-svn: 96892

llvm-svn: 96891

I don't have a small testcase for this.

llvm-svn: 96890