llvm-svn: 24083

llvm-svn: 24082

This allows us to turn code like malloc(4*x+4) -> malloc int, (x+1)

llvm-svn: 24081

change.

llvm-svn: 24076

llvm-svn: 24056

PR640

llvm-svn: 24046

llvm-svn: 24044

into the LLVMAnalysis library.
This allows LLVMTranform and LLVMTransformUtils to be archives and linked
with LLVMAnalysis.a, which provides any missing definitions.

llvm-svn: 24036

llvm-svn: 24033

into: malloc int, (2*X)

llvm-svn: 24032

(malloc [25 x int]) directly without having to convert to
(malloc [100 x sbyte]) first.

llvm-svn: 24031

llvm-svn: 24030

   SparcV9 JIT.
2. Make LLVMTransformUtils a relinked object file and always link it before
   LLVMAnalysis.a.  These two libraries have circular dependencies on each
   other which creates problem when building the SparcV9 JIT.  This change
   fixes the dependency on all platforms problems with a minimum of fuss.

llvm-svn: 24023

fixes a very slow compile in PR639.

llvm-svn: 24011

llvm-svn: 23998

llvm-svn: 23973

one use (but one is a cast).  This handles the very common case of:

 X = alloc [n x byte]
 Y = cast X to somethingbetter
 seteq X, null

In order to avoid infinite looping when there are multiple casts, we only
allow this if the xform is strictly increasing the alignment of the
allocation.

llvm-svn: 23961

where the second has less alignment required.  If we had explicit alignment
support in the IR, we could handle this case, but we can't until we do.

llvm-svn: 23960

more effective at promoting these allocations, catching them earlier in the
compile process.

llvm-svn: 23959

llvm-svn: 23958

llvm-svn: 23944

llvm-svn: 23943

llvm-svn: 23940

This should speed up build times.

llvm-svn: 23933

code

llvm-svn: 23931

pointer marking the end of the list, the zero *must* be cast to the pointer
type.  An un-cast zero is a 32-bit int, and at least on x86_64, gcc will
not extend the zero to 64 bits, thus allowing the upper 32 bits to be
random junk.

The new END_WITH_NULL macro may be used to annotate a such a function
so that GCC (version 4 or newer) will detect the use of un-casted zero
at compile time.

llvm-svn: 23888

allow pointer types.

llvm-svn: 23859

inner loop like this:

LBB_RateConvertMono8AltiVec_2:  ; no_exit
        lis r2, ha16(.CPI_RateConvertMono8AltiVec_0)
        lfs f3, lo16(.CPI_RateConvertMono8AltiVec_0)(r2)
        fmr f3, f3
        fadd f0, f2, f0
        fadd f3, f0, f3
        fcmpu cr0, f3, f1
        bge cr0, LBB_RateConvertMono8AltiVec_2  ; no_exit

to an inner loop like this:

LBB_RateConvertMono8AltiVec_1:  ; no_exit
        fsub f2, f2, f1
        fcmpu cr0, f2, f1
        fmr f0, f2
        bge cr0, LBB_RateConvertMono8AltiVec_1  ; no_exit

Doh! good catch!

llvm-svn: 23838

all but main.  If it's not set, we can still internalize, but only if an
explicit symbol list is provided.

llvm-svn: 23783

llvm-svn: 23773

llvm-svn: 23772

llvm-svn: 23771

out CSE's of base expressions it could build a result whose order was
nondet.

llvm-svn: 23698

from the end of a vector instead of the beginning

llvm-svn: 23697

llvm-svn: 23695

llvm-svn: 23677

llvm-svn: 23674

llvm-svn: 23673

IV strides dependend on the pointer order of the strides in memory.
Non-determinism is bad.

llvm-svn: 23672

llvm-svn: 23656