llvm-svn: 123048

llvm-svn: 114750

llvm-svn: 109092

llvm-svn: 107276

llvm-svn: 106833

llvm-svn: 103457

Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.

llvm-svn: 101579

with a fix for self-hosting

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101465

llvm-svn: 101434

with a fix

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101397

llvm-svn: 101368

of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101364

llvm-svn: 101334

llvm-svn: 100709

isInteger, we now have isFloatTy and isIntegerTy.  Requested by Chris!

llvm-svn: 96223

Avoid going through the LLVMContext for type equality where it's safe to dereference the type pointer.

llvm-svn: 92726

 Intrinsic::dbg_stoppoint
 Intrinsic::dbg_region_start
 Intrinsic::dbg_region_end
 Intrinsic::dbg_func_start

llvm-svn: 92672

just throw them away.

llvm-svn: 86678

so get rid of eh.selector.i64 and rename eh.selector.i32 to eh.selector.
Likewise for eh.typeid.for.  This aligns us with gcc, which always uses a
32 bit value for the selector on all platforms.  My understanding is that
the register allocator used to assert if the selector intrinsic size didn't
match the pointer size, and this was the reason for introducing the two
variants.  However my testing shows that this is no longer the case (I
fixed some bugs in selector lowering yesterday, and some more today in the
fastisel path; these might have caused the original problems).

llvm-svn: 84106

where the element is of a basic builtin type.  For example, to get
an i8* use getInt8PtrTy.

llvm-svn: 83379

update all code that this affects.

llvm-svn: 79830

llvm-svn: 78948

metadata related, which I'm waiting on to avoid conflicting with Devang.

llvm-svn: 77721

Revert the ConstantInt constructors back to their 2.5 forms where possible, thanks to contexts-on-types.  More to come.

llvm-svn: 77011

llvm-svn: 76702

llvm-svn: 75703

This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640

llvm-svn: 75630

Begin the painful process of tearing apart the rat'ss nest that is Constants.cpp and ConstantFold.cpp.
This involves temporarily hard wiring some parts to use the global context.  This isn't ideal, but it's
the only way I could figure out to make this process vaguely incremental.

llvm-svn: 75445

implemented in codegen, have no frontend to generate them, and are 
better implemented with pattern matching (like the ppc backend does
to generate rlwimi/rlwinm etc).

PR4543

llvm-svn: 75430

Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.

llvm-svn: 75379

and abort()/exit() -> llvm_report_error().

llvm-svn: 75363

llvm-svn: 75040

we had multiple type planes and these lookups were expensive.

llvm-svn: 74319

llvm-svn: 74143

llvm-svn: 71587

memcpy, memmove and memset.

llvm-svn: 71427

and extern_weak_odr.  These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global.  In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time.   This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function.  If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body.  The
code generators on the other hand map weak and weak_odr linkage
to the same thing.

llvm-svn: 66339

llvm-svn: 64040

Thanks, Duncan.

llvm-svn: 63389