reference to a pointer, so that it can handle the case where DataLayout
is not available and behave conservatively.

llvm-svn: 174024

llvm-svn: 172614

library rename.

llvm-svn: 171747

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

llvm-svn: 169250

with different sizes.

llvm-svn: 167018

llvm-svn: 165403

IRBuilder, DIBuilder, etc.

This is the proper layering as MDBuilder can't be used (or implemented)
without the Core Metadata representation.

Patches to Clang and Dragonegg coming up.

llvm-svn: 160237

This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.

I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.

I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.

Thanks to Bill and Eric for giving the green light for this bit of cleanup.

llvm-svn: 159421

llvm-svn: 154850

through the use of 'fpmath' metadata.  Currently this only provides a 'fpaccuracy'
value, which may be a number in ULPs or the keyword 'fast', however the intent is
that this will be extended with additional information about NaN's, infinities
etc later.  No optimizations have been hooked up to this so far.

llvm-svn: 154822

Add support for vectors of pointers.

llvm-svn: 145801

flip these tests around.

llvm-svn: 138708

llvm-svn: 135375

can be used to turn a <4 x i64> into a <4 x i32> but getCastOpcode would assert
if you passed these types to it.  Note that this strictly extends the previous
functionality: if getCastOpcode previously accepted two vector types (i.e. didn't
assert) then it still will and returns the same opcode (BitCast).  That's because
before it would only accept vectors with the same bitwidth, and the new code only
touches vectors with the same length.  However if two vectors have both the same
bitwidth and the same length then their element types have the same bitwidth, so
the new logic will return BitCast as before.

llvm-svn: 131530

llvm-svn: 129271

had gotten out of sync: isCastable didn't think it was possible to
cast the x86_mmx type to anything, while it did think it possible
to cast an i64 to x86_mmx.

llvm-svn: 128705

llvm-svn: 123026

Fixes potential ambiguity problems on VS 2010.

Patch by nobled!

llvm-svn: 110029

llvm-svn: 98850

llvm-svn: 98761

llvm-svn: 98634

llvm-svn: 98632

llvm-svn: 98628

llvm-svn: 98625

adjusted unittest

I have added some doxygen to OptionalOperandTraits,
so hopefully there will be no confusion in the future.

Incidentally OptionalOperandTraits is not used any more (IIUC),
but the obvious client would be BranchInstr, and I plan
to rearrange it that way.

llvm-svn: 98624

llvm-svn: 98623