llvm-svn: 21353

llvm-svn: 21352

llvm-svn: 21351

them away.

llvm-svn: 21350

llvm-svn: 21349

llvm-svn: 21348

llvm-svn: 21347

llvm-svn: 21346

bits that must be passed up the inheritance hierarchy.  Convert MForm and AForm
instructions over

llvm-svn: 21345

finished up, only resolve fully when the def is defined.  This allows things
to be changed and all uses to be propagated through.  This implements
TableGen/LazyChange.td and fixes TemplateArgRename.td in the process.

None of the .td files used in LLVM backends are changed at all by this
patch.

llvm-svn: 21344

llvm-svn: 21343

llvm-svn: 21342

llvm-svn: 21341

llvm-svn: 21340

llvm-svn: 21339

llvm-svn: 21338

llvm-svn: 21337

llvm-svn: 21336

will lead to it being rejected though.

llvm-svn: 21335

int %bar(float %a, float %b, float %c, float %d) {
entry:
    %tmp.1 = setlt float %a, %d
    %tmp.2 = setlt float %b, %d
    %or = or bool %tmp.1, %tmp.2
    %tmp.3 = setgt float %c, %d
    %tmp.4 = or bool %or, %tmp.3
    %tmp.5 = and bool %tmp.4, true
    %retval = cast bool %tmp.5 to int
    ret int %retval
}

We now emit:

_bar:
.LBB_bar_0:     ; entry
        fcmpu cr0, f1, f4
        fcmpu cr1, f2, f4
        cror 0, 0, 4
        fcmpu cr1, f3, f4
        cror 28, 0, 5
        mfcr r2
        rlwinm r3, r2, 29, 31, 31
        blr

Instead of:

_bar:
.LBB_bar_0:     ; entry
        fcmpu cr7, f1, f4
        mfcr r2
        rlwinm r2, r2, 29, 31, 31
        fcmpu cr7, f2, f4
        mfcr r3
        rlwinm r3, r3, 29, 31, 31
        or r2, r2, r3
        fcmpu cr7, f3, f4
        mfcr r3
        rlwinm r3, r3, 30, 31, 31
        or r3, r2, r3
        blr

llvm-svn: 21321

llvm-svn: 21320

llvm-svn: 21319

llvm-svn: 21318

llvm-svn: 21317

        // (X != 0) | (Y != 0) -> (X|Y != 0)
        // (X == 0) & (Y == 0) -> (X|Y == 0)

Compiling this:

int %bar(int %a, int %b) {
        entry:
        %tmp.1 = setne int %a, 0
        %tmp.2 = setne int %b, 0
        %tmp.3 = or bool %tmp.1, %tmp.2
        %retval = cast bool %tmp.3 to int
        ret int %retval
        }

to this:

_bar:
        or r2, r3, r4
        addic r3, r2, -1
        subfe r3, r3, r2
        blr

instead of:

_bar:
        addic r2, r3, -1
        subfe r2, r2, r3
        addic r3, r4, -1
        subfe r3, r3, r4
        or r3, r2, r3
        blr

llvm-svn: 21316

eliminating an and for Nate's testcase:

int %bar(int %a, int %b) {
        entry:
        %tmp.1 = setne int %a, 0
        %tmp.2 = setne int %b, 0
        %tmp.3 = or bool %tmp.1, %tmp.2
        %retval = cast bool %tmp.3 to int
        ret int %retval
        }

generating:

_bar:
        addic r2, r3, -1
        subfe r2, r2, r3
        addic r3, r4, -1
        subfe r3, r3, r4
        or r3, r2, r3
        blr

instead of:

_bar:
        addic r2, r3, -1
        subfe r2, r2, r3
        addic r3, r4, -1
        subfe r3, r3, r4
        or r2, r2, r3
        rlwinm r3, r2, 0, 31, 31
        blr

llvm-svn: 21315

  register.  Added support in the .td file for the g5-specific variant
  of cr -> gpr moves that executes faster, but we currently don't
  generate it.

llvm-svn: 21314

llvm-svn: 21313

llvm-svn: 21312

llvm-svn: 21311

llvm-svn: 21310

Add new ppc beta option related to using condition registers
Make pattern isel control flag (-enable-pattern-isel) global and tristate
  0 == off
  1 == on
  2 == target default

llvm-svn: 21309

llvm-svn: 21307

This pass forward branches through conditions when it can show that the
conditions is either always true or false for a predecessor.  This currently
only handles the most simple cases of this, but is successful at threading
across 2489 branches and 65 switch instructions in 176.gcc, which isn't bad.

llvm-svn: 21306

llvm-svn: 21305

llvm-svn: 21304

llvm-svn: 21303

a 21264 fix, and fix the operator precidence on an and -> zap check (should fix hundreds of test cases

llvm-svn: 21302

llvm-svn: 21301

easier on the eyes, not that numbers like 18446744073709541376 are bad or
anything

llvm-svn: 21300