| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
matcher to emit mnemonics contain '.' characters. This makes asm parser code simpler and more efficient.
llvm-svn: 186397
|
| |
|
|
|
|
|
|
| |
powerpc-linux Fedora 12.
g++ (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)
llvm-svn: 186396
|
| |
|
|
|
|
|
| |
Intrinsics already existed for the 64-bit variants, so these support operations
of size at most 32-bits.
llvm-svn: 186392
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch enables calls to __aeabi_idivmod when in EABI mode,
by using the remainder value returned on registers (R1),
enabled by the ARM triple "none-eabi". Note that Darwin and
GNUEABI triples will continue lowering on GNU style, that is,
using the stack for the remainder.
Still need to add SREM/UREM support fix for 64-bit lowering.
llvm-svn: 186390
|
| |
|
|
| |
llvm-svn: 186371
|
| |
|
|
|
|
|
|
|
| |
This change mirrors the changes that were made to the X86 and ARM targets to
support subtarget feature changing. As indicated in r182899, the mechanism is
still undergoing revision, and so as with the X86 and ARM targets, there is no
test case yet (there is no effective functionality change).
llvm-svn: 186357
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PPCInstrInfo::insertSelect and PPCInstrInfo::canInsertSelect were computing the
common subclass of the true and false inputs, and then selecting either the
32-bit or the 64-bit isel variant based on the result of calling
PPC::GPRCRegClass.hasSubClassEq(RC) and PPC::G8RCRegClass.hasSubClassEq(RC)
(where RC is the common subclass). Unfortunately, this is not quite right: if
we have something like this:
%vreg8<def> = SELECT_CC_I8 %vreg4<kill>, %vreg7<kill>, %vreg6<kill>, 76;
G8RC_and_G8RC_NOX0:%vreg8 CRRC:%vreg4 G8RC_NOX0:%vreg7,%vreg6
then the common subclass of G8RC_and_G8RC_NOX0 and G8RC_NOX0 is G8RC_NOX0, and
G8RC_NOX0 is not a subclass of G8RC (because it also contains the ZERO8
pseudo-register). As a result, we also need to check the common subclass
against GPRC_NOR0 and G8RC_NOX0 explicitly.
This had not been a problem for clients of insertSelect that called
canInsertSelect first (because it had a compensating mistake), but insertSelect
is also used by the PPC pseudo-instruction expander, and this error was causing
a problem in that context.
This problem was found by csmith.
llvm-svn: 186343
|
| |
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=65873
llvm-svn: 186339
|
| |
|
|
| |
llvm-svn: 186321
|
| |
|
|
| |
llvm-svn: 186311
|
| |
|
|
| |
llvm-svn: 186309
|
| |
|
|
| |
llvm-svn: 186308
|
| |
|
|
| |
llvm-svn: 186307
|
| |
|
|
| |
llvm-svn: 186301
|
| |
|
|
|
|
| |
Patch by Job!
llvm-svn: 186291
|
| |
|
|
| |
llvm-svn: 186283
|
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
|
|
|
| |
between ELF (Linux, FreeBSD, NetBSD) and OSX as platform for the
assembler dialect.
llvm-svn: 186252
|
| |
|
|
| |
llvm-svn: 186227
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ARM paired GPR COPY was being lowered to two MOVr without CC. This
patch puts the CC back.
My test is a reduction of the case where I encountered the issue,
64-bit atomics use paired GPRs.
The issue only occurs with selectionDAG, FastISel doesn't encounter it
so I didn't bother calling it.
llvm-svn: 186226
|
| |
|
|
| |
llvm-svn: 186222
|
| |
|
|
| |
llvm-svn: 186212
|
| |
|
|
| |
llvm-svn: 186196
|
| |
|
|
|
|
| |
radar://14351991
llvm-svn: 186189
|
| |
|
|
|
|
|
|
|
|
| |
Fixes a 35% degradation compared to unvectorized code in
MiBench/automotive-susan and an equally serious regression on a private
image processing benchmark.
radar://14351991
llvm-svn: 186188
|
| |
|
|
|
|
|
|
|
|
|
| |
Address calculation for gather/scather in vectorized code can incur a
significant cost making vectorization unbeneficial. Add infrastructure to add
cost.
Tests and cost model for targets will be in follow-up commits.
radar://14351991
llvm-svn: 186187
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186182
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186181
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186180
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186179
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186178
|
| |
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186177
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In particular:
movsbw %al, %ax --> cbtw
movswl %ax, %eax --> cwtl
movslq %eax, %rax --> cltq
According to Intel's manual those have the same performance characteristics but
come with a smaller encoding.
llvm-svn: 186174
|
| |
|
|
|
|
|
|
| |
possible
Patch by Andrea Di Biagio
llvm-svn: 186165
|
| |
|
|
|
|
| |
cases are added.
llvm-svn: 186151
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Normal (sext (setcc ...)) sequences are optimised into
(select_cc ..., -1, 0) by DAGCombiner::visitSIGN_EXTEND.
However, this is deliberately not done for vectors, and after
vector type legalization we have (sext_inreg (setcc ...)) instead.
I wondered about trying to extend DAGCombiner to handle this case too,
but it seemed to be a loss on some other targets I tried, even those for
which SETCC isn't "legal" and SELECT_CC is.
llvm-svn: 186149
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GPR and FPR constraints like "{r2}" and "{f2}" weren't handled correctly
because the name-to-regno mapping depends on the value type and
(because of that) the internal names in RegStrings are not the
same as the AsmName.
CC constraints like "{cc}" didn't work either because there was no
associated register class.
llvm-svn: 186148
|
| |
|
|
|
|
|
| |
If the source of these instructions is spilled we should load the destination.
If the destination is spilled we should store the source.
llvm-svn: 186147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds explicit calling convention types for the Win64 and
System V/x86-64 ABIs. This allows code to override the default, and use
the Win64 convention on a target that wants to use SysV (and
vice-versa). This is needed to implement the `ms_abi` and `sysv_abi` GNU
attributes.
Reviewers:
CC:
llvm-svn: 186144
|
| |
|
|
|
|
|
|
|
|
| |
We had patterns to match v4i32 immAllZerosV -> V_SET0, but not patterns for
v8i16 (which occurs in the test case) or v16i8. The same was true for
V_SETALLONES (so I added the associated patterns for those as well).
Another bug found by llvm-stress.
llvm-svn: 186108
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug (found by csmith) at -O0 where we attempt to create a RLWIMI
with an out-of-range operand. Most uses of the isRunOfOnes function are guarded
by a condition that the value is not zero. This was not true in two places, and
in both places a zero input would result in an out-of-rage MB value (= 32).
To fix this, isRunOfOnes returns false on a zero input (and I've remove one
now-redundant guard).
llvm-svn: 186101
|
| |
|
|
|
|
| |
Extend r186072 to handle shifts and ANDs.
llvm-svn: 186073
|
| |
|
|
|
|
|
|
|
|
|
|
| |
RISBG can handle some ANDs for which no AND IMMEDIATE exists.
It also acts as a three-operand AND for some cases where an
AND IMMEDIATE could be used instead.
It might be worth adding a pass to replace RISBG with AND IMMEDIATE
in cases where the register operands end up being the same and where
AND IMMEDIATE is smaller.
llvm-svn: 186072
|
| |
|
|
|
|
|
|
|
|
|
|
| |
RISBG has three 8-bit operands (I3, I4 and I5). I'd originally
restricted all three to 6 bits, since that's the only range we intended
to use at the time. However, the top bit of I4 acts as a "zero" flag for
RISBG, while the top bit of I3 acts as a "test" flag for RNSBG & co.
This patch therefore allows them to have the full 8-bit range.
I've left the fifth operand as a 6-bit value for now since the
upper 2 bits have no defined meaning.
llvm-svn: 186070
|
| |
|
|
|
|
| |
intended.
llvm-svn: 186017
|
| |
|
|
| |
llvm-svn: 186013
|
| |
|
|
|
|
|
| |
Enough for the radeonsi driver to use it for calculating derivatives.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186012
|
| |
|
|
|
|
|
| |
lit test coverage to follow in the next commit.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186011
|
| |
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186010
|
| |
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186009
|