three or four registers and VLD2 (multiple two-element structures) which loads
memory into two double-spaced registers.

A8.6.307 & A8.6.310

llvm-svn: 96980

llvm-svn: 96978

llvm-svn: 96977

that refer to an undefined class.

llvm-svn: 96976

llvm-svn: 96975

disables load folding at -O0.

llvm-svn: 96973

no id's would cause early exit allowing IsLegalToFold to return true
instead of false, producing a cyclic dag.

This was striking the new isel because it isn't using SelectNodeTo yet,
which theoretically is just an optimization.

llvm-svn: 96972

llvm-svn: 96971

the result is integral.  Fixes <rdar://problem/7676608>.

llvm-svn: 96970

The MicroBlaze is a highly configurable 32-bit soft-microprocessor for
use on Xilinx FPGAs. For more information see:
http://www.xilinx.com/tools/microblaze.htm
http://en.wikipedia.org/wiki/MicroBlaze

The current LLVM MicroBlaze backend generates assembly which can be
compiled using the an appropriate binutils assembler.

llvm-svn: 96969

llvm-svn: 96968

segment.

llvm-svn: 96967

so that it doesn't break them when the code generator starts using it.

llvm-svn: 96966

llvm-svn: 96965

llvm-svn: 96964

to be aligned with optimal nops.  This patch does not change any functionality
and when the compiler is changed to use EmitCodeAlignment() it should also not
change the resulting output.  Once the compiler change is made and everything
looks good the next patch with the table of optimal X86 nops will be added to
WriteNopData() changing the output.  There are many FIXMEs in this patch which
will be removed when we have better target hooks (coming soon I hear).

llvm-svn: 96963

llvm-svn: 96962

llvm-svn: 96961

llvm-svn: 96960

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