This patch is an incremental step towards supporting a flat symbol table.
It de-overloads the intrinsic functions by providing type-specific intrinsics
and arranging for automatically upgrading from the old overloaded name to
the new non-overloaded name. Specifically:
  llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64
  llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64
  llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64
  llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64
  llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64
New code should not use the overloaded intrinsic names. Warnings will be
emitted if they are used.

llvm-svn: 25366

llvm-svn: 25355

used by the C backend.

llvm-svn: 25267

llvm-svn: 24300

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

llvm-svn: 22523

with the CBE

llvm-svn: 21875

llvm-svn: 21874

looks completely untested. :(

llvm-svn: 21873

warning from the CBE+GCC.

llvm-svn: 21779

population (ctpop).  Generic lowering is implemented, however only promotion
is implemented for SelectionDAG at the moment.

More coming soon.

llvm-svn: 21676

llvm-svn: 21639

llvm-svn: 21629

llvm-svn: 21420

llvm-svn: 20900

using Function::arg_{iterator|begin|end}.  Likewise Module::g* -> Module::global_*.

This patch is contributed by Gabor Greif, thanks!

llvm-svn: 20597

llvm-svn: 20382

llvm-svn: 20375

llvm-svn: 15334

llvm-svn: 14622

llvm-svn: 14266

llvm-svn: 14187

llvm-svn: 14159

llvm-svn: 14134

  isunordered(X, Y) === isnan(X) | isnan(Y)

Remove isunordered, add isnan.

llvm-svn: 14132

llvm-svn: 14127

Work around for bogus errors: no those static functions don't need to
be executed to be initialized!

llvm-svn: 14040

llvm-svn: 13432

llvm-svn: 11483

prototypes, even if they don't precisely match what it would prefer to use.
This fixes: CBackend/2004-02-15-PreexistingExternals.llx compiling it into:

  ltmp_0_30 = memcpy(l14_C, 4u, 17);
  ltmp_1_30 = memcpy(((int *)l27_A), ((unsigned )(long)l27_B), ((int )123u));

instead of:

  ltmp_0_30 = memcpy(l14_C, 4u, 17);
  ltmp_1_27 = l43_memcpy(l27_A, l27_B, 123u);

Which does the wrong thing as you could imagine.

llvm-svn: 11481

intrinsic will always produce zero), but it will behave unexpectedly, so
warn like GCC does.

llvm-svn: 11444

llvm-svn: 11431

Patch graciously contributed by Reid Spencer!

llvm-svn: 11355

llvm-svn: 11349

llvm-svn: 10858

code generators completely ignore them.

llvm-svn: 10691

implementation from the TargetMachine directly.

llvm-svn: 10636

llvm-svn: 10623

llvm-svn: 10621