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

loads
branches
setcc
working calls
Global address
External addresses

now I can manage malloc calls.

llvm-svn: 23887

llvm-svn: 23886

llvm-svn: 23884

llvm-svn: 23882

the input is that type, this caused a failure on gs on X86 last night.
Move the hard checks into Build[US]Div since that is where decisions like
this should be made.

llvm-svn: 23881

to group appropriately and provide cues to maintainers that the lists don't
need to be ordered.

llvm-svn: 23880

llvm-svn: 23878

2005-10-21-longlonggtu.ll.

llvm-svn: 23875

let the generic code handle it.  This fixes CodeGen/Generic/2005-10-21-longlonggtu.ll on ppc.

also, reindent this code

llvm-svn: 23874

llvm-svn: 23870

llvm-svn: 23868

For example, we can now join things like [0-30:0)[31-40:1)[52-59:2)
with [40:60:0) if the 52-59 range is defined by a copy from the 40-60 range.
The resultant range ends up being [0-30:0)[31-60:1).

This fires a lot through-out the test suite (e.g. shrinking bc from
19492 -> 18509 machineinstrs) though most gains are smaller (e.g. about
50 copies eliminated from crafty).

llvm-svn: 23866

(an unused method).

Fix the merger so that it can merge ranges like this  [10:12)[16:40) with
[12:38) into [10:40) instead of bogus ranges.  This sort of input will be
possible for the merger coming shortly

llvm-svn: 23865

haven't seen it fire on our testsuite.

llvm-svn: 23863

allow pointer types.

llvm-svn: 23859

llvm-svn: 23858

llvm-svn: 23857

llvm-svn: 23856

llvm-svn: 23855

Add a new flag to TargetLowering indicating if the target has really cheap
  signed division by powers of two, make ppc use it.  This will probably go
  away in the future.
Implement some more ISD::SDIV folds in the dag combiner
Remove now dead code in the x86 backend.

llvm-svn: 23853

Inst cleanup.  As a bonus, operands are in the correct order for cmovs.  Expect new stuff to pass in the JIT tonight

llvm-svn: 23852

llvm-svn: 23851

Andrew for bringing this to my attn.

llvm-svn: 23850

llvm-svn: 23849

llvm-svn: 23848

for types that aren't legal, and fail a divisor is less than zero
comparison, which would cause us to drop a subtract.

llvm-svn: 23846

llvm-svn: 23845

llvm-svn: 23844

llvm-svn: 23843

llvm-svn: 23842

Fix a *bug* in the extendIntervalEndTo method.  In particular, if adding
[2:10) to an interval containing [0:2),[10:30), we produced [0:10),[10,30).
Which is not the most smart thing to do.  Now produce [0:30).

llvm-svn: 23841

llvm-svn: 23839

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

for some common ops and use them for a few examples.  Andrew, if you like
this, feel free to convert the rest over, if you hate it, feel free to
revert.

llvm-svn: 23837

llvm-svn: 23836

that the nodes can be folded with other nodes, and we can not duplicate
code in every backend.  Alpha will probably want this too.

llvm-svn: 23835

llvm-svn: 23833

still lots of uglyness.
Maybe calls will come soon.
Fixing the return value of things will be necessary to make alpha work.

llvm-svn: 23832

Regression/CodeGen/Generic/2004-02-08-UnwindSupport.llx

llvm-svn: 23831