- No intended functionality change.

llvm-svn: 65805

giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types. 

Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved 
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.

As part of this, some types have been renamed:

  TypeOfExpr -> TypeOfExprType
  FunctionTypeProto -> FunctionProtoType
  FunctionTypeNoProto -> FunctionNoProtoType

There shouldn't be any functionality change...

llvm-svn: 65591

 - For types whose native representation is a pointer.

 - Use to replace ExprConstant.cpp:HasPointerEvalType,
   CodeGenFunction::isObjCPointerType.

llvm-svn: 65569

 - No functionality change.

llvm-svn: 65560

llvm-svn: 65533

 - <rdar://problem/6622451> Bad x86_64 code gen for message call taking one argument.

llvm-svn: 65510

code) when calling noreturn functions; general expression emission
isn't ready to do the right thing in all cases.

llvm-svn: 65473

 - No functionality change.

llvm-svn: 65325

memory using Indirect; this was a holdover from when CGCall wasn't as
robust.

llvm-svn: 65278

as byval. Otherwise LLVM will have its own opinion about where to put
things.

We now pass all gcc dg.compat tests on x86_64.

llvm-svn: 65266

about these much but <2 x i16> shows up in the gcc test suite.

llvm-svn: 65264

Also, make sure to pass <1 x i64> as i64 (not <1 x i64>, which doesn't
quite work yet in the backend).

llvm-svn: 65262

clear insertion point. The rest of IRgen should theoretically take
advantage of this to avoid emitting dead code. Theory != Practice.

llvm-svn: 65141

 - Remove an unused variant of EmitCallExpr overload.

llvm-svn: 65130

llvm-svn: 65114

We are down to only failing gcc.dg/compat/vector-[12] (8 tests total).

llvm-svn: 64967

Two more gcc/x86_64 failures down.

llvm-svn: 64963

things passed in mixed registers.

This knocks out 8 x86_64 failures.

llvm-svn: 64958

1. Return of _Complex long double used wrong type.

2. va_arg of types passed in two SSE registers didn't account for
extra space in register save area.

Down to 18 failures on gcc/compat/x86_64. Combined 32/64 results are:
--
		=== gcc Summary ===

# of expected passes		1292
# of unexpected failures	34
# of unsupported tests		2
--

llvm-svn: 64880

llvm-svn: 64756

llvm-svn: 64727

llvm-svn: 64701

ASTContext types.

llvm-svn: 64533

important for both keeping the generated LLVM simple and for ensuring
that integer types are passed/promoted correctly.

llvm-svn: 64529

 - Now at 1274 passes on gcc compat suite vs 1262.

llvm-svn: 64469

 - Doesn't yet handle case where values are passed in mixed (general
   purpose & floating point) registers; otherwise largely
   functional. Code still needs some cleaning.

Fixes:
MultiSource/Applications/lua/lua
MultiSource/Applications/siod/siod
MultiSource/Applications/sqlite3/sqlite3
SingleSource/Regression/C/PR640
SingleSource/UnitTests/2003-07-09-SignedArgs
SingleSource/UnitTests/2007-03-02-VaCopy

gcc compat test suite results (Darwin x86-32 & -64):
--
# of expected passes		1262
# of unexpected failures	56
# of unresolved testcases	34
# of unsupported tests		2

Compare to: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090209/012050.html

llvm-svn: 64370

llvm-svn: 64235

llvm-svn: 64221

memory representation (e.g., bool).
 - This upgrades (downgrades) MultiSource/Applications/ClamAV/clamscan
   to a miscompile and fixes
   SingleSource/UnitTests/2003-05-31-CastToBool.

llvm-svn: 64194

ABI.

llvm-svn: 64187

 - Currently, this is producing poor code, but we prefer correctness
   to performance for now. Eventually we should be able to generally
   avoid having to set the alignment when we control the alignment of
   the alloca.

 - This knocks out 33/1000 failures on my single argument ABI tests,
   down to 22/1000 and 18 of these appear to be gcc bugs. Woot.

llvm-svn: 64001

 - No intended functionality change, this is essentially enabling
   direct passing of complex and aggregate values, which no ABI is
   using.

llvm-svn: 63863

value.
 - No functionality change.

llvm-svn: 63859

 - No intended functionality change, all current ABI implementations
   were only using indirect for complex/aggregate types, which were
   being passed indirectly with the Direct ABIInfo kind.

llvm-svn: 63858

 - No (intended) functionality change, the semantic changes are to come.

llvm-svn: 63850

llvm-svn: 63845

llvm-svn: 63813

llvm-svn: 63811

information.

llvm-svn: 63799

llvm-svn: 63794