llvm-svn: 19379

llvm-svn: 19370

llvm-svn: 19320

llvm-svn: 19319

llvm-svn: 19315

llvm-svn: 19306

llvm-svn: 19305

  * We can now fold cast instructions into select instructions that
    have at least one constant operand.
  * We now optimize expressions more aggressively based on bits that are
    known to be zero.  These optimizations occur a lot in code that uses
    bitfields even in simple ways.
  * We now turn more cast-cast sequences into AND instructions.  Before we
    would only do this if it if all types were unsigned.  Now only the
    middle type needs to be unsigned (guaranteeing a zero extend).
  * We transform sign extensions into zero extensions in several cases.

This corresponds to these test/Regression/Transforms/InstCombine testcases:
  2004-11-22-Missed-and-fold.ll
  and.ll: test28-29
  cast.ll: test21-24
  and-or-and.ll
  cast-cast-to-and.ll
  zeroext-and-reduce.ll

llvm-svn: 19220

SimplifyCFG is one of those passes that we use for final cleanup: it should
not rely on other passes to clean up its garbage.  This fixes the "why are
trivially dead setcc's in the output of gccas" problem.

llvm-svn: 19212

llvm-svn: 19180

llvm-svn: 18958

turning X - (constantexpr) into X + (-constantexpr) among other things.

llvm-svn: 18935

llvm-svn: 18913

do not insert a prototype for malloc of: void* malloc(uint): on 64-bit u
targets this is not correct.  Instead of prototype it as void *malloc(...),
and pass the correct intptr_t through the "...".

Finally, fix Regression/CodeGen/SparcV9/2004-12-13-MallocCrash.ll, by not
forming constantexpr casts from pointer to uint.

llvm-svn: 18908

llvm-svn: 18843

in some cases.

llvm-svn: 18842

llvm-svn: 18841

llvm-svn: 18840

llvm-svn: 18839

In particular, implement div.ll:test10 and rem.ll:test4.

llvm-svn: 18838

failures from last night.

llvm-svn: 18832

This fixes a crash compiling TimberWolfMC that was exposed due to recent
optimizer changes.

llvm-svn: 18831

in SPEC, the subsequent optimziations that we are after don't play with
with FP values, so disable this xform for them.  Really we just don't want
stuff like:

double G;   (always 0 or 412312.312)
  = G;

turning into:

bool G_b;
  = G_b ? 412312.312 : 0;

We'd rather just do the load.

-Chris

llvm-svn: 18819

down to actually BE a bool.  This allows simple value range propagation
stuff work harder, deleting comparisons in bzip2 in some hot loops.

This implements GlobalOpt/integer-bool.ll, which is the essence of the
loop condition distilled into a testcase.

llvm-svn: 18817

if the other side is overdefined.

This allows us to fold conditions like:  if (X < Y || Y > Z) in some cases.

llvm-svn: 18807

llvm-svn: 18800

llvm-svn: 18799

 1. Actually increment the Statistic for the GV elim optzn
 2. When resolving undef branches, only resolve branches in executable blocks,
    avoiding marking a bunch of completely dead blocks live.  This has a big
    impact on the quality of the generated code.

With this patch, we positively rip up vortex, compiling Ut_MoveBytes to a
single memcpy call. In vortex we get this:

     12 ipsccp           - Number of globals found to be constant
    986 ipsccp           - Number of arguments constant propagated
   1378 ipsccp           - Number of basic blocks unreachable
   8919 ipsccp           - Number of instructions removed

llvm-svn: 18796

llvm-svn: 18795

non-address-taken global variables.

llvm-svn: 18790

In functions where we fully constant prop the return value, replace all
ret instructions with 'ret undef'.

llvm-svn: 18786

llvm-svn: 18781

llvm-svn: 18776

and the failure on make_dparser last night.

llvm-svn: 18766

This implements SCCP/ipsccp-basic.ll, rips apart Olden/mst (as described in
PR415), and does other nice things.

There is still more to come with this, but it's a start.

llvm-svn: 18752

llvm-svn: 18693

llvm-svn: 18692

successor block.  This turns cases like this:

x = a op b
if (c) {
  use x
}

into:

if (c) {
  x = a op b
  use x
}

This triggers 3965 times in spec, and is tested by
Regression/Transforms/InstCombine/sink_instruction.ll

This appears to expose a bug in the X86 backend for 177.mesa, which I'm
looking in to.

llvm-svn: 18677

llvm-svn: 18674

llvm-svn: 18670