llvm-svn: 51304

llvm-svn: 51303

  (add (sext x), cst) --> (sext (add x, cst'))
  (add (sext x), (sext y)) --> (sext (add int x, y))
  (add double (sitofp x), fpcst) --> (sitofp (add int x, intcst))
  (add double (sitofp x), (sitofp y)) --> (sitofp (add int x, y))

This generally reduces conversions.  For example MiBench/telecomm-gsm
gets these simplifications:

HACK2: 	%tmp67.i142.i.i = sext i16 %tmp6.i141.i.i to i32		; <i32> [#uses=1]
	%tmp23.i139.i.i = sext i16 %tmp2.i138.i.i to i32		; <i32> [#uses=1]
	%tmp8.i143.i.i = add i32 %tmp67.i142.i.i, %tmp23.i139.i.i		; <i32> [#uses=3]
HACK2: 	%tmp67.i121.i.i = sext i16 %tmp6.i120.i.i to i32		; <i32> [#uses=1]
	%tmp23.i118.i.i = sext i16 %tmp2.i117.i.i to i32		; <i32> [#uses=1]
	%tmp8.i122.i.i = add i32 %tmp67.i121.i.i, %tmp23.i118.i.i		; <i32> [#uses=3]
HACK2: 	%tmp67.i.i190.i = sext i16 %tmp6.i.i189.i to i32		; <i32> [#uses=1]
	%tmp23.i.i187.i = sext i16 %tmp2.i.i186.i to i32		; <i32> [#uses=1]
	%tmp8.i.i191.i = add i32 %tmp67.i.i190.i, %tmp23.i.i187.i		; <i32> [#uses=3]
HACK2: 	%tmp67.i173.i.i.i = sext i16 %tmp6.i172.i.i.i to i32		; <i32> [#uses=1]
	%tmp23.i170.i.i.i = sext i16 %tmp2.i169.i.i.i to i32		; <i32> [#uses=1]
	%tmp8.i174.i.i.i = add i32 %tmp67.i173.i.i.i, %tmp23.i170.i.i.i		; <i32> [#uses=3]
HACK2: 	%tmp67.i152.i.i.i = sext i16 %tmp6.i151.i.i.i to i32		; <i32> [#uses=1]
	%tmp23.i149.i.i.i = sext i16 %tmp2.i148.i.i.i to i32		; <i32> [#uses=1]
	%tmp8.i153.i.i.i = add i32 %tmp67.i152.i.i.i, %tmp23.i149.i.i.i		; <i32> [#uses=3]
HACK2: 	%tmp67.i.i.i.i = sext i16 %tmp6.i.i.i.i to i32		; <i32> [#uses=1]
	%tmp23.i.i5.i.i = sext i16 %tmp2.i.i.i.i to i32		; <i32> [#uses=1]
	%tmp8.i.i7.i.i = add i32 %tmp67.i.i.i.i, %tmp23.i.i5.i.i		; <i32> [#uses=3]


This also fixes a bug in ComputeNumSignBits handling select and
makes it more aggressive with and/or.

llvm-svn: 51302

llvm-svn: 51301

llvm-svn: 51300

Reclaim memory from chains of ScopedDecls, and reclaim memory for the initializers of EnumConstantDecls.

llvm-svn: 51299

llvm-svn: 51298

Fixed a bug in ParmVarDecl::param_end(): Handle the case where there are no
ParmVarDecls for a FunctionDecl, but its function prototype has formal arguments
(can happen with typedefs).

llvm-svn: 51297

llvm-svn: 51296

value as undef or untracked.

llvm-svn: 51295

llvm-svn: 51294

will become first-class types.

llvm-svn: 51293

replaced is a PHI. This prevents it from inserting uses before defs
in the case that it isn't a PHI and it depends on other instructions
later in the block. This fixes the 447.dealII regression on x86-64.

llvm-svn: 51292

llvm-svn: 51291

llvm-svn: 51290

llvm-svn: 51289

llvm-svn: 51288

llvm-svn: 51287

1) Sema::ParseAST now constructs a TranslationUnit object to own the top-level Decls, which releases the top-level Decls upon exiting ParseAST.

2) Bug fix: TranslationUnit::~TranslationUnit handles the case where a Decl is added more than once as a top-level Decl.

3) Decl::Destroy is now a virtual method, obviating the need for a special dispatch based on DeclKind.

3) FunctionDecl::Destroy now releases its Body using its Destroy method.

4) Added Stmt::Destroy and Stmt::DestroyChildren, which recursively delete the child ASTs of a Stmt and call their dstors.  We may need to special case dstor/Destroy methods for particular Stmt subclasses that own other dynamically allocated objects besides AST nodes.

5) REGRESSION: We temporarily are not deallocating attributes; a FIXME is provided.

llvm-svn: 51286

implement bitfield codegen (although I don't envy the person who 
implements it).  This also prevents a crash on code like that from PR2309
(it's still broken, but it fails more gracefully).

llvm-svn: 51285

llvm-svn: 51284

llvm-svn: 51282

llvm-svn: 51281

llvm-svn: 51280

code in SelectionDAG.

llvm-svn: 51279

Added Stmt::DestroyChildren, which will be used by the dstors of the subclasses of Stmt to recursively delete their child AST nodes.

llvm-svn: 51278

$non_lazy_ptr's and $lazy_ptr's.

llvm-svn: 51277

code).

llvm-svn: 51276

llvm-svn: 51275

llvm-svn: 51274

it a few days to make sure there aren't any significant regressions.

llvm-svn: 51273

produce a negative zero.

llvm-svn: 51272

to accurately represent the integer.  This triggers 9 times in 471.omnetpp,
though 8 of those seem to be inlined from the same place.

llvm-svn: 51271

llvm-svn: 51269

type and the other operand is a constant into integer comparisons.
This happens surprisingly frequently (e.g. 10 times in 471.omnetpp),
which are things like this:

	%tmp8283 = sitofp i32 %tmp82 to double	
	%tmp1013 = fcmp ult double %tmp8283, 0.0

Clearly comparing tmp82 against i32 0 is cheaper here.

this also triggers 8 times in gobmk, including this one:

	%tmp375376 = sitofp i32 %tmp375 to double
	%tmp377 = fcmp ogt double %tmp375376, 8.150000e+01

which is comparing an integer against 81.5 :).

llvm-svn: 51268

llvm-svn: 51267

llvm-svn: 51266

and "int a = {};").  I'll adjust the tests in a bit.

llvm-svn: 51265

llvm-svn: 51264

intersecting bits.  This triggers all over the place, for example in lencode,
with adds of stuff like:

	%tmp580 = mul i32 %tmp579, 2	
	%tmp582 = and i32 %b8, 1
and

	%tmp28 = shl i32 %abs.i, 1		
	%sign.0 = select i1 %tmp23, i32 1, i32 0
and
	%tmp344 = shl i32 %tmp343, 2	
	%tmp346 = and i32 %tmp96, 3

etc.

llvm-svn: 51263