Commit Graph

193 Commits

Author SHA1 Message Date
Richard Sandiford
396e080b34 [SystemZ] Fix incorrect use of RISBG for a zero-extended right shift
We would wrongly transform the testcase into the equivalent of an AND with 1.
The problem was that, when testing whether the shifted-in bits of the right
shift were significant, we used the width of the final zero-extended result
rather than the width of the shifted value.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195731 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-26 10:53:16 +00:00
Richard Sandiford
b83bf52113 [SystemZ] Fix TMHH and TMHL usage for z10 with -O0
I've no idea why I decided to handle TMxx differently from all the other
high/low logic operations, but it was a stupid thing to do.  The high
registers aren't available as separate 32-bit registers on z10,
so subreg_h32 can't be used on a GR64 there.

I've normally been testing with z196 and with -O3 and so hadn't noticed
this until now.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195473 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 17:28:28 +00:00
Richard Sandiford
793ce99ea7 [SystemZ] Automatically detect zEC12 and z196 hosts
As on other hosts, the CPU identification instruction is priveleged,
so we need to look through /proc/cpuinfo.  I copied the PowerPC way of
handling "generic".

Several tests were implicitly assuming z10 and so failed on z196.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193742 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-31 12:14:17 +00:00
Richard Sandiford
349baa6039 [SystemZ] Set usaAA to true
useAA significantly improves the handling of vector code that has TBAA
information attached.  It also helps other cases, as shown by the testsuite
changes here.  The only real downside I've seen is that it interferes with
MergeConsecutiveStores.  The problem is that that optimization works top
down, starting at the first store in the chain, and looks for cases where
the chain result is only used by a single related store.  These related
stores don't alias, so useAA will have rewritten all the later stores to
use a different chain input (typically the same one as the first store).

I think the advantages outweigh the disadvantages though, so for now I've
just disabled alias analysis for the unaligned-01.ll test.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193521 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-28 13:53:37 +00:00
Richard Sandiford
a7be36c8eb [DAGCombiner] Respect volatility when checking for aliases
Making useAA() default to true for SystemZ showed that the combiner alias
analysis wasn't handling volatile accesses.  This hit many of the SystemZ
tests, but I arbitrarily picked one for the purpose of this patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193518 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-28 12:00:00 +00:00
Richard Sandiford
66589dcc8f Keep TBAA info when rewriting SelectionDAG loads and stores
Most SelectionDAG code drops the TBAA info when creating a new form of a
load and store (e.g. during legalization, or when converting a plain
load to an extending one).  This patch tries to catch all cases where
the TBAA information can legitimately be carried over.

The patch adds alternative forms of getLoad() and getExtLoad() that take
a MachineMemOperand instead of individual fields.  (The corresponding
getTruncStore() already exists.)  The idea is to use the MachineMemOperand
forms when all fields are carried over (size, pointer info, isVolatile,
isNonTemporal, alignment and TBAA info).  If some adjustment is being
made, e.g. to narrow the load, then we still pass the individual fields
but also pass the TBAA info.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193517 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-28 11:17:59 +00:00
Richard Sandiford
f9a5e40b90 Replace sra with srl if a single sign bit is required
E.g. (and (sra (i32 x) 31) 2) -> (and (srl (i32 x) 30) 2).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192884 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-17 11:16:57 +00:00
Richard Sandiford
d77a7669ec [SystemZ] Handle extensions in RxSBG optimizations
The input to an RxSBG operation can be narrower as long as the upper bits
are don't care.  This fixes a FIXME added in r192783.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192790 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-16 13:35:13 +00:00
Richard Sandiford
d1a4f579bf [SystemZ] Improve handling of SETCC
We previously used the default expansion to SELECT_CC, which in turn would
expand to "LHI; BRC; LHI".  In most cases it's better to use an IPM-based
sequence instead.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192784 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-16 11:10:55 +00:00
Richard Sandiford
5d7e93c0d4 Handle (shl (anyext (shr ...))) in SimpilfyDemandedBits
This is really an extension of the current (shl (shr ...)) -> shl optimization.
The main difference is that certain upper bits must also not be demanded.

The motivating examples are the first two in the testcase, which occur
in llvmpipe output.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192783 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-16 10:26:19 +00:00
Richard Sandiford
f8f993b675 [SystemZ] Use A(G)SI when spilling the target of a constant addition
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192681 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-15 08:42:59 +00:00
Richard Sandiford
e22c56d6d8 [SystemZ] Add comparisons of high words and memory
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191777 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 15:00:44 +00:00
Richard Sandiford
185ef05ad6 [SystemZ] Add comparisons of large immediates using high words
There are no corresponding patterns for small immediates because they would
prevent the use of fused compare-and-branch instructions.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191775 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:56:23 +00:00
Richard Sandiford
ad366a3f67 [SystemZ] Add immediate addition involving high words
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191774 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:53:46 +00:00
Richard Sandiford
bd1958d8e9 [SystemZ] Extend test-under-mask support to high GR32s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191773 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:41:52 +00:00
Richard Sandiford
f985f01574 [SystemZ] Extend 32-bit RISBG optimizations to high words
This involves using RISB[LH]G, whereas the equivalent z10 optimization
uses RISBG.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191770 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:36:20 +00:00
Richard Sandiford
00f5335ea0 [SystemZ] Extend pseudo conditional 8- and 16-bit stores to high words
As the comment says, we always want to use STOC for 32-bit stores.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191767 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:33:55 +00:00
Richard Sandiford
6d2158acae [SystemZ] Add test missing from r191764.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191765 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:31:50 +00:00
Richard Sandiford
b9dcca8265 [SystemZ] Allow integer AND involving high words
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191762 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:20:41 +00:00
Richard Sandiford
1ff62e182e [SystemZ] Allow integer XOR involving high words
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191759 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 14:08:44 +00:00
Richard Sandiford
1c831f7f1f [SystemZ] Allow integer OR involving high words
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191755 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 13:22:41 +00:00
Richard Sandiford
645d250b84 [SystemZ] Allow integer insertions with a high-word destination
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191753 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 13:18:56 +00:00
Richard Sandiford
4708657097 [SystemZ] Allow selects with a high-word destination
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191751 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 13:10:16 +00:00
Richard Sandiford
4c8feae136 [SystemZ] Add patterns to load a constant into a high word (IIHF)
Similar to low words, we can use the shorter LLIHL and LLIHH if it turns
out that the other half of the GR64 isn't live.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191750 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 13:02:28 +00:00
Richard Sandiford
79e2ed4d83 [SystemZ] Add register zero extensions involving at least one high word
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191746 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 12:49:07 +00:00
Richard Sandiford
9813dbf396 [SystemZ] Add truncating high-word stores (STCH and STHH)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191743 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 12:22:49 +00:00
Richard Sandiford
9a05f040e7 [SystemZ] Add zero-extending high-word loads (LLCH and LLHH)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191742 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 12:19:08 +00:00
Richard Sandiford
ced450f0e6 [SystemZ] Add sign-extending high-word loads (LBH and LHH)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191740 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 12:11:47 +00:00
Richard Sandiford
55d7d83b6c [SystemZ] Use upper words of GR64s for codegen
This just adds the basics necessary for allocating the upper words to
virtual registers (move, load and store).  The move support is parameterised
in a way that makes it easy to handle zero extensions, but the associated
zero-extend patterns are added by a later patch.

The easiest way of testing this seemed to be add a new "h" register
constraint for high words.  I don't expect the constraint to be useful
in real inline asms, but it should work, so I didn't try to hide it
behind an option.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191739 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-01 11:26:28 +00:00
Manman Ren
e267f04ef5 TBAA: update tbaa format from scalar format to struct-path aware format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191690 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-30 18:17:55 +00:00
Manman Ren
9e81c3bdb2 TBAA: handle scalar TBAA format and struct-path aware TBAA format.
Remove the command line argument "struct-path-tbaa" since we should not depend
on command line argument to decide which format the IR file is using. Instead,
we check the first operand of the tbaa tag node, if it is a MDNode, we treat
it as struct-path aware TBAA format, otherwise, we treat it as scalar TBAA
format.

When clang starts to use struct-path aware TBAA format no matter whether
struct-path-tbaa is no, and we can auto-upgrade existing bc files, the support
for scalar TBAA format can be dropped.

Existing testing cases are updated to use the struct-path aware TBAA format.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191538 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-27 18:34:27 +00:00
Richard Sandiford
0548a5487a [SystemZ] Rein back the use of block operations
The backend tries to use block operations like MVC, NC, OC and XC for
simple scalar operations.  For correctness reasons, it rejects any case
in which the regions might partially overlap.  However, for performance
reasons, it should also reject cases where the regions might be equal,
since the instruction might then not use the fast path.

This fixes a performance regression seen in bzip2.  We may want to limit
the optimisation even more in future, or even remove it entirely, but I'll
try with this for now.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191525 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-27 15:29:20 +00:00
Richard Sandiford
8dac19c070 [SystemZ] Improve handling of PC-relative addresses
The backend previously folded offsets into PC-relative addresses
whereever possible.  That's the right thing to do when the address
can be used directly in a PC-relative memory reference (using things
like LRL).  But if we have a register-based memory reference and need
to load the PC-relative address separately, it's better to use an anchor
point that could be shared with other accesses to the same area of the
variable.

Fixes a FIXME.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191524 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-27 15:14:04 +00:00
Richard Sandiford
e2d6f91d63 [SystemZ] Add unsigned compare-and-branch instructions
For some reason I never got around to adding these at the same time as
the signed versions.  No idea why.

I'm not sure whether this SystemZII::BranchC* stuff is useful, or whether
it should just be replaced with an "is normal" flag.  I'll leave that
for later though.

There are some boundary conditions that can be tweaked, such as preferring
unsigned comparisons for equality with [128, 256), and "<= 255" over "< 256",
but again I'll leave those for a separate patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190930 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-18 09:56:40 +00:00
Richard Sandiford
219d2b8695 [SystemZ] Improve extload handling
The port originally had special patterns for extload, mapping them to the
same instructions as sextload.  It seemed neater to have patterns that
match "an extension that is allowed to be signed" and "an extension that
is allowed to be unsigned".

This was originally meant to be a clean-up, but it does improve the handling
of promoted integers a little, as shown by args-06.ll.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190777 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-16 09:03:10 +00:00
Richard Sandiford
856bf59433 [SystemZ] Try to fold shifts into TMxx
E.g. "SRL %r2, 2; TMLL %r2, 1" => "TMLL %r2, 4".


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190672 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-13 09:09:50 +00:00
Richard Sandiford
299fdd814f [SystemZ] Add TM and TMY
The main complication here is that TM and TMY (the memory forms) set
CC differently from the register forms.  When the tested bits contain
some 0s and some 1s, the register forms set CC to 1 or 2 based on the
value the uppermost bit.  The memory forms instead set CC to 1
regardless of the uppermost bit.

Until now, I've tried to make it so that a branch never tests for an
impossible CC value.  E.g. NR only sets CC to 0 or 1, so branches on the
result will only test for 0 or 1.  Originally I'd tried to do the same
thing for TM and TMY by using custom matching code in ISelDAGToDAG.
That ended up being very ugly though, and would have meant duplicating
some of the chain checks that the common isel code does.

I've therefore gone for the simpler alternative of adding an extra
operand to the TM DAG opcode to say whether a memory form would be OK.
This means that the inverse of a "TM;JE" is "TM;JNE" rather than the
more precise "TM;JNLE", just like the inverse of "TMLL;JE" is "TMLL;JNE".
I suppose that's arguably less confusing though...


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-10 10:20:32 +00:00
Richard Sandiford
aff1c6427c [SystemZ] Tweak integer comparison code
The architecture has many comparison instructions, including some that
extend one of the operands.  The signed comparison instructions use sign
extensions and the unsigned comparison instructions use zero extensions.
In cases where we had a free choice between signed or unsigned comparisons,
we were trying to decide at lowering time which would best fit the available
instructions, taking things like extension type into account.  The code
to do that was getting increasingly hairy and was also making some bad
decisions.  E.g. when comparing the result of two LLCs, it is better to use
CR rather than CLR, since CR can be fused with a branch while CLR can't.

This patch removes the lowering code and instead adds an operand to
integer comparisons to say whether signed comparison is required,
whether unsigned comparison is required, or whether either is OK.
We can then leave the choice of instruction up to the normal isel code.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190138 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-06 11:51:39 +00:00
Richard Sandiford
867f9501f6 [SystemZ] Use XC for a memset of 0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190130 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-06 10:25:07 +00:00
Richard Sandiford
16277c4698 [SystemZ] Add NC, OC and XC
For now these are just used to handle scalar ANDs, ORs and XORs in which
all operands are memory.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190041 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-05 10:36:45 +00:00
Richard Sandiford
8bce43648b [SystemZ] Add support for TMHH, TMHL, TMLH and TMLL
For now this just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189819 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-03 15:38:35 +00:00
Richard Sandiford
477168192c [SystemZ] Add support for TMHH, TMHL, TMLH and TMLL
For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189469 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-28 10:31:43 +00:00
Richard Sandiford
47e7096094 [SystemZ] Extend memcmp support to all constant lengths
This uses the infrastructure added for memcpy and memmove in r189331.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189458 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-28 09:01:51 +00:00
Richard Sandiford
842a1be06c [SystemZ] Extend memcpy and memset support to all constant lengths
Lengths up to a certain threshold (currently 6 * 256) use a series of MVCs.
Lengths above that threshold use a loop to handle X*256 bytes followed
by a single MVC to handle the excess (if any).  This loop will also be
needed in future when support for variable lengths is added.

Because the same tablegen classes are used to define MVC and CLC,
the patch also has the side-effect of defining a pseudo loop instruction
for CLC.  That instruction isn't used yet (and wouldn't be handled correctly
if it were).  I'm planning to use it soon though.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189331 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-27 09:54:29 +00:00
Richard Sandiford
a550b51bac [SystemZ] Add basic prefetch support
Just the instructions and intrinsics for now.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189100 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 11:36:42 +00:00
Richard Sandiford
35c93e4e42 [SystemZ] Try reversing comparisons whose first operand is in memory
This allows us to make more use of the many compare reg,mem instructions.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189099 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 11:27:19 +00:00
Richard Sandiford
65ddcfa8c1 [SystemZ] Prefer LHI;ST... over LAY;MV...
If we had a store of an integer to memory, and the integer and store size
were suitable for a form of MV..., we used MV... no matter what.  We could
then have sequences like:

    lay %r2, 0(%r3,%r4)
    mvi 0(%r2), 4

In these cases it seems better to force the constant into a register
and use a normal store:

    lhi %r2, 4
    stc %r2, 0(%r3, %r4)

since %r2 is more likely to be hoisted and is easier to rematerialize.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189098 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 11:18:53 +00:00
Richard Sandiford
a8a7099c18 Turn MipsOptimizeMathLibCalls into a target-independent scalar transform
...so that it can be used for z too.  Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.

The pass is opt-in because at the moment it only handles sqrt.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 10:27:02 +00:00
Richard Sandiford
df40f8e8ad [SystemZ] Define remainig *MUL_LOHI patterns
The initial port used MLG(R) for i64 UMUL_LOHI but left the other three
combinations as not-legal-or-custom.  Although 32x32->{32,32}
multiplications exist, they're not as quick as doing a normal 64-bit
multiplication, so it didn't seem like i32 SMUL_LOHI and UMUL_LOHI
would be useful.  There's also no direct instruction for i64 SMUL_LOHI,
so it needs to be implemented in terms of UMUL_LOHI.

However, not defining these patterns means that we don't convert
division by a constant into multiplication, so this patch fills
in the other cases.  The new i64 SMUL_LOHI sequence is simpler
than the one that we used previously for 64x64->128 multiplication,
so int-mul-08.ll now tests the full sequence.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188898 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 09:34:56 +00:00
Richard Sandiford
d95865a2a2 [SystemZ] Use FI[EDX]BRA for codegen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188895 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 09:04:20 +00:00