the examples shared to make sure the shared library keeps working.

llvm-svn: 96959

llvm-svn: 96958

Speed up cycle checking significantly by caching results.

llvm-svn: 96956

handle NaN properly.

Do (X une Y) ? X : Y  -> X if one of X and Y is not zero.

llvm-svn: 96955

llvm-svn: 96954

getelementptr. Despite only doing so in the case where x is a known
array object and c can be converted to an index within range, this
could still be invalid if c is actually the address of an object
allocated outside of LLVM. Also, SCEVExpander, the original motivation
for this code, has since been improved to avoid inttoptr+ptroint in
more cases.

llvm-svn: 96950

x86 and x86_64 on UNIX systems. Only OS X 10.6.2 (x86_64) and 32bit CentOS 5.2
with gcc 4.1.2 were tested. ARM UNIX build triggered failure motivating this
modification, as it seems that the ARM ABI does not support _Unwind_GetIP(...),
_Unwind_SetGR(...), and _Unwind_SetIP(...). From doing a quick browse of:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf,
it seems as if all other exception related apis are supported. Looks like
the port can be done to ARM. Thanks to Xerxes Rånby <xerxes@zafena.se> for
pointing out this error.

llvm-svn: 96949

llvm-svn: 96948

llvm-svn: 96944

llvm-svn: 96943

llvm-svn: 96942

llvm-svn: 96941

llvm-svn: 96938

llvm-svn: 96936

capable compilers (which could be llvm-gcc or clang).

llvm-svn: 96935

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