unpredicated. That is, turn
subeq r0, r1, #1
addne r0, r1, #1
into
sub r0, r1, #1
addne r0, r1, #1
For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
op r1, ...
str r1, [r10] ; end-of-life of r1 as div result
cmp r0, #65
movne r1, #44 ; raw dependency on previous r1
moveq r1, #12
If movne is unpredicated, then
op r1, ...
str r1, [r10]
cmp r0, #65
mov r1, #44 ; r1 written unconditionally
moveq r1, #12
Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.
This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.
rdar://8951196
llvm-svn: 146914
This change reduces the number of instructions generated.
For example,
(load (add (sub $n0, $n1), (MipsLo got(s))))
results in the following sequence of instructions:
1. sub $n2, $n0, $n1
2. lw got(s)($n2)
Previously, three instructions were needed.
1. sub $n2, $n0, $n1
2. addiu $n3, $n2, got(s)
3. lw 0($n3)
llvm-svn: 146888
Now that getMatchingSuperRegClass() returns accurate results, it can be
used to compute constraints imposed by instructions using a sub-register
of a virtual register.
This means we can recompute the register class of any virtual register
by combining the constraints from all its uses.
llvm-svn: 146874
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().
Delete the old manual, error-prone implementations in the targets.
llvm-svn: 146873
Teach TableGen to create the missing register classes needed for
getMatchingSuperRegClass() to return maximal results. The function is
still not auto-generated, so it still returns inexact results.
This produces these new register classes:
ARM:
QQPR_with_dsub_0_in_DPR_8
QQQQPR_with_dsub_0_in_DPR_8
X86:
GR64_with_sub_32bit_in_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOSP
GR64_with_sub_16bit_in_GR16_NOREX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX
GR64_TC_and_GR64_with_sub_32bit_in_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX_NOSP
GR64_TCW64_and_GR64_with_sub_32bit_in_GR32_NOAX
GR64_TC_and_GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_NOREX
GR64_with_sub_32bit_in_GR32_TC
GR64_with_sub_32bit_in_GR32_ABCD_and_GR32_NOAX
GR64_with_sub_32bit_in_GR32_NOAX_and_GR32_TC
GR64_with_sub_32bit_in_GR32_AD
GR64_with_sub_32bit_in_GR32_AD_and_GR32_NOAX
The other targets in the tree are not weird enough to be affected.
llvm-svn: 146872
And fix the double-[]. It was including the [] as part of
the project name somehow, resulting in PACKAGE_TARNAME "-llvm-"
and a strange docdir default:
./configure --help | grep docdir
--docdir=DIR documentation root [DATAROOTDIR/doc/-llvm-]
llvm-svn: 146849
internal nightly testers. Original commit message:
By popular demand, link up types by name if they are isomorphic and one is an
autorenamed version of the other. This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large
app.
llvm-svn: 146838
make VariadicFunction actually be trivial. Do so, and also make it look
more like your standard trivial functor by making it a struct with no
access specifiers. The unit test is updated to initialize its functors
properly.
llvm-svn: 146827
This adjustment is already included in the block offsets computed by
BasicBlockInfo, and adjusting again here can cause the pass to loop.
When CreateNewWater splits a basic block, OffsetIsInRange would reject
the new CPE on the next pass because of the too conservative alignment
adjustment. This caused the block to be split again, and so on.
llvm-svn: 146751
Jim Grosbach