[PowerPC] Add some InstAlias definitions

Summary:
This patch add the InstAlias definitions for below instructions.

ADDI ADDIS ADDI8 ADDIS8
RLWINM8
ISEL ISEL8
OR OR_rec ORI ORI8 XORI8
CNTLZW8 CNTLZW

[PowerPC] Add some InstAlias definitions

Summary:
This patch add the InstAlias definitions for below instructions.

ADDI ADDIS ADDI8 ADDIS8
RLWINM8
ISEL ISEL8
OR OR_rec ORI ORI8 XORI8
CNTLZW8 CNTLZW8_rec
TEND TSR
RFEBB
NOR NOR_rec
MTCRF
SUBF SUBF_rec SUBFC SUBFC_rec
RLDICL_32_64
TW

Reviewed By: steven.zhang

Differential Revision: https://reviews.llvm.org/D77559

show more ...

[PowerPC] Ignore implicit register operands for MCInst

Summary:
When doing the conversion: MachineInst -> MCInst, we should ignore the
implicit operands, it will expose more opportunity for InstiAli

[PowerPC] Ignore implicit register operands for MCInst

Summary:
When doing the conversion: MachineInst -> MCInst, we should ignore the
implicit operands, it will expose more opportunity for InstiAlias.

Reviewed By: steven.zhang

Differential Revision: https://reviews.llvm.org/D77118

show more ...

[PowerPC] Regenerate optcmp.ll test checks to fix issue reported on D77354

[PowerPC] Recommit r314244 with refactoring and off by default

This re-commits everything that was pulled in r314244. The transformation
is off by default (patch to enable it to follow). The code is

[PowerPC] Recommit r314244 with refactoring and off by default

This re-commits everything that was pulled in r314244. The transformation
is off by default (patch to enable it to follow). The code is refactored
to have a single entry-point and provide fine-grained control over patterns
that it selects. This patch also fixes the bugs in the original code.

Everything that failed with the original patch has been re-tested with this
patch (with the transformation turned on). So the patch to turn this on is
soon to follow.

Differential Revision: https://reviews.llvm.org/D38575

llvm-svn: 319434

show more ...

[PowerPC] Reverting sequence of patches for elimination of comparison instructions

In the past while, I've committed a number of patches in the PowerPC back end
aimed at eliminating comparison instr

[PowerPC] Reverting sequence of patches for elimination of comparison instructions

In the past while, I've committed a number of patches in the PowerPC back end
aimed at eliminating comparison instructions. However, this causes some failures
in proprietary source and these issues are not observed in SPEC or any open
source packages I've been able to run.
As a result, I'm pulling the entire series and will refactor it to:
- Have a single entry point for easy control
- Have fine-grained control over which patterns we transform

A side-effect of this is that test cases for these patches (and modified by
them) are XFAIL-ed. This is a temporary measure as it is counter-productive
to remove/modify these test cases and then have to modify them again when
the refactored patch is recommitted.
The failure will be investigated in parallel to the refactoring effort and
the recommit will either have a fix for it or will leave this transformation
off by default until the problem is resolved.

llvm-svn: 314244

show more ...

[PowerPC] Eliminate compares - add i64 sext/zext handling for SETLT/SETGT

As mentioned in https://reviews.llvm.org/D33718, this simply adds another
pattern to the compare elimination sequence and is

[PowerPC] Eliminate compares - add i64 sext/zext handling for SETLT/SETGT

As mentioned in https://reviews.llvm.org/D33718, this simply adds another
pattern to the compare elimination sequence and is committed without a
differential review.

llvm-svn: 314106

show more ...

[PowerPC] Expand ISEL instruction into if-then-else sequence.

Generally, the ISEL is expanded into if-then-else sequence, in some
cases (like when the destination register is the same with the true

[PowerPC] Expand ISEL instruction into if-then-else sequence.

Generally, the ISEL is expanded into if-then-else sequence, in some
cases (like when the destination register is the same with the true
or false value register), it may just be expanded into just the if
or else sequence.

llvm-svn: 292154

show more ...

Revert "[PowerPC] Expand ISEL instruction into if-then-else sequence."

This reverts commit 1d0e0374438ca6e153844c683826ba9b82486bb1.

llvm-svn: 292131

[PowerPC] Expand ISEL instruction into if-then-else sequence.

Generally, the ISEL is expanded into if-then-else sequence, in some
cases (like when the destination register is the same with the true

[PowerPC] Expand ISEL instruction into if-then-else sequence.

Generally, the ISEL is expanded into if-then-else sequence, in some
cases (like when the destination register is the same with the true
or false value register), it may just be expanded into just the if
or else sequence.

llvm-svn: 292128

show more ...

Adding -verify-machineinstrs option to PowerPC tests

Currently we have a number of tests that fail with -verify-machineinstrs.
To detect this cases earlier we add the option to the testcases with th

Adding -verify-machineinstrs option to PowerPC tests

Currently we have a number of tests that fail with -verify-machineinstrs.
To detect this cases earlier we add the option to the testcases with the
exception of tests that will currently fail with this option. PR 27456 keeps
track of this failures.

No code review, as discussed with Hal Finkel.

llvm-svn: 277624

show more ...

[PPC] Enable transformations in PPCPassConfig::addIRPasses at O2

http://reviews.llvm.org/D18562

A large number of testcases has been modified so they pass after this test.
One testcase is deleted,

[PPC] Enable transformations in PPCPassConfig::addIRPasses at O2

http://reviews.llvm.org/D18562

A large number of testcases has been modified so they pass after this test.
One testcase is deleted, because I realized even after undoing the original
change that was committed with this testcase, the testcase still passes. So
I removed it. The change to one other testcase (test/CodeGen/PowerPC/pr25802.ll)
is an arbitrary change to keep it passing. Given the original intention of the
testcase, and the fact that fixing it will require some time to change the testcase,
we concluded that this quick change will be enough.

llvm-svn: 265683

show more ...

Add CR-bit tracking to the PowerPC backend for i1 values

This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as sepa

Add CR-bit tracking to the PowerPC backend for i1 values

This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:

- Reduction in register pressure (because we no longer need GPRs to store
boolean values).

- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).

- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.

Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).

This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.

It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).

POWER7 test-suite performance results (from 10 runs in each configuration):

SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup

SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown

llvm-svn: 202451

show more ...

PPC popcnt[dw] do not have record forms

The instruction definitions incorrectly specified that popcntd and popcntw have
record forms; they do not. This mistake was causing invalid code generation.

PPC popcnt[dw] do not have record forms

The instruction definitions incorrectly specified that popcntd and popcntw have
record forms; they do not. This mistake was causing invalid code generation.

llvm-svn: 195272

show more ...

TBAA: remove !tbaa from testing cases when they are not needed.

This will make it easier to turn on struct-path aware TBAA since the metadata
format will change.

llvm-svn: 188944

PPCInstrInfo::optimizeCompareInstr should not optimize FP compares

The floating-point record forms on PPC don't set the condition register bits
based on a comparison with zero (like the integer reco

PPCInstrInfo::optimizeCompareInstr should not optimize FP compares

The floating-point record forms on PPC don't set the condition register bits
based on a comparison with zero (like the integer record forms do), but rather
based on the exception status bits.

llvm-svn: 181423

show more ...

Fix PPC optimizeCompareInstr swapped-sub argument handling

When matching a compare with a subtract where the arguments of the compare are
swapped w.r.t. the arguments of the subtract, we need to neg

Fix PPC optimizeCompareInstr swapped-sub argument handling

When matching a compare with a subtract where the arguments of the compare are
swapped w.r.t. the arguments of the subtract, we need to negate the predicates
(or CR bit indices) of the users. This, however, is not the same as inverting
the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM
backend seems to do this correctly, but when I adapted the code for the PPC
backend, I introduced an error in this logic.

Comparison optimization is now enabled again by default.

llvm-svn: 179899

show more ...

Disable PPC comparison optimization by default

This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.

llvm-svn: 179807

Implement optimizeCompareInstr for PPC

Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
z

Implement optimizeCompareInstr for PPC

Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.

This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.

llvm-svn: 179802

show more ...