Breaks windows bot.
This reverts commit r265050.
This reverts commit r265055.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265062 91177308-0d34-0410-b5e6-96231b3b80d8
"blockaddress" can not apply to an external function. All
blockaddress constant uses must belong to the same module as the
definition of the target function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265061 91177308-0d34-0410-b5e6-96231b3b80d8
This patch simply mirrors the attributes we give to @llvm.nvvm.reflect
to the __nvvm_reflect libdevice call. This shaves about 30% of the code
in libdevice away because of CSE opportunities. It's also helps us
figure out that libdevice implementations of transcendental functions
don't have side-effects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265060 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change will allow loads with imp-def to be clustered in machine-scheduler pass.
areMemAccessesTriviallyDisjoint() can also handle loads with imp-def.
Reviewers: mcrosier, jmolloy, t.p.northover
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18665
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265051 91177308-0d34-0410-b5e6-96231b3b80d8
Chapter 3 of the QPX manual states that, "Scalar floating-point load
instructions, defined in the Power ISA, cause a replication of the source data
across all elements of the target register." Thus, if we have a load followed
by a QPX splat (from the first lane), the splat is redundant. This adds a late
MI-level pass to remove the redundant splats in some of these cases
(specifically when both occur in the same basic block).
This optimization is scheduled just prior to post-RA scheduling. It can't happen
before anything that might replace the load with some already-computed quantity
(i.e. store-to-load forwarding).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265047 91177308-0d34-0410-b5e6-96231b3b80d8
We don't really support non-constant shuffle masks, but these tests are for cases where BUILD_VECTOR is made up from vector extracts (as well as undef/zero scalars).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265045 91177308-0d34-0410-b5e6-96231b3b80d8
Only force "extern" linkage if the function used to be a definition
in the source module. Declarations keep their original linkage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265043 91177308-0d34-0410-b5e6-96231b3b80d8
For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting LLVM_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265041 91177308-0d34-0410-b5e6-96231b3b80d8
The default is legal, which results in 'Cannot select' errors. This is
triggered during selfhost due to a recent cost model change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265040 91177308-0d34-0410-b5e6-96231b3b80d8
This will become necessary in a subsequent change to make this method
merge adjacent stack adjustments, i.e. it might erase the previous
and/or next instruction.
It also greatly simplifies the calls to this function from Prolog-
EpilogInserter. Previously, that had a bunch of logic to resume iteration
after the call; now it just continues with the returned iterator.
Note that this changes the behaviour of PEI a little. Previously,
it attempted to re-visit the new instruction created by
eliminateCallFramePseudoInstr(). That code was added in r36625,
but I can't see any reason for it: the new instructions will obviously
not be pseudo instructions, they will not have FrameIndex operands,
and we have already accounted for the stack adjustment.
Differential Revision: http://reviews.llvm.org/D18627
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265036 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Upstream googletest prints "Running main() from gtest_main.cc" to stdout prior
to running tests. LLVM removed that print statement in r61540. If a user were
to use lit to run tests that use upstream googletest, however, lit
reports "Running main()" as an invalid test name.
To avoid such a failure, add an extra conditional to `formats/googletest.py`.
Also add tests to demonstrate the modified behavior.
Reviewers: abdulras, ddunbar
Subscribers: ddunbar, llvm-commits, kastiglione
Differential Revision: http://reviews.llvm.org/D18606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265034 91177308-0d34-0410-b5e6-96231b3b80d8
The test case added in r265023 is failing on ninja-x64-msvc-RA-centos6.
Update the test to make less specific assumptions on code generation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265026 91177308-0d34-0410-b5e6-96231b3b80d8
If the lhs is evaluated before the rhs, FuncletI's operator-> can trigger the
assert(isHandleInSync() && "invalid iterator access!");
at include/llvm/ADT/DenseMap.h:1061. (Happens e.g. when compiled with GCC 6.)
Differential Revision: http://reviews.llvm.org/D18440
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265024 91177308-0d34-0410-b5e6-96231b3b80d8
PPCSimplifyAddress contains this code:
IntegerType *OffsetTy = ((VT == MVT::i32) ? Type::getInt32Ty(*Context)
: Type::getInt64Ty(*Context));
to determine the type to be used for an index register, if one needs
to be created. However, the "VT" here is the type of the data being
loaded or stored, *not* the type of an address. This means that if
a data element of type i32 is accessed using an index that does not
not fit into 32 bits, a wrong address is computed here.
Note that PPCFastISel is only ever used on 64-bit currently, so the type
of an address is actually *always* MVT::i64. Other parts of the code,
even in this same PPCSimplifyAddress routine, already rely on that fact.
Thus, this patch changes the code to simply unconditionally use
Type::getInt64Ty(*Context) as OffsetTy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265023 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change will handle missing store pair opportunity where the first store
instruction stores zero followed by the non-zero store. For example, this change
will convert :
str wzr, [x8]
str w1, [x8, #4]
into:
stp wzr, w1, [x8]
Reviewers: jmolloy, t.p.northover, mcrosier
Subscribers: flyingforyou, aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18570
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265021 91177308-0d34-0410-b5e6-96231b3b80d8
The fast isel pass currently emits a COPY_TO_REGCLASS node to convert
from a F4RC to a F8RC register class during conversion of a
floating-point number to integer. There is actually no support in the
common code instruction printers to emit COPY_TO_REGCLASS nodes, so the
PowerPC back-end has special code there to simply ignore
COPY_TO_REGCLASS.
This is correct *if and only if* the source and destination registers of
COPY_TO_REGCLASS are the same (except for the different register class).
But nothing guarantees this to be the case, and if the register
allocator does end up allocating source and destination to different
registers after all, the back-end simply generates incorrect code. I've
included a test case that shows such incorrect code generation.
However, it seems that COPY_TO_REGCLASS is actually not intended to be
used at the MI layer at all. It is used during SelectionDAG, but always
lowered to a plain COPY before emitting MI. Other back-end's fast isel
passes never emit COPY_TO_REGCLASS at all. I suspect it is simply wrong
for the PowerPC back-end to emit it here.
This patch changes the PowerPC back-end to directly emit COPY instead of
COPY_TO_REGCLASS and removes the special handling in the instruction
printers.
Differential Revision: http://reviews.llvm.org/D18605
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265020 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are too many instructions to exhaustively test so addiu and lwc2 are
used as representative examples.
It should be noted that many memory instructions that should have simm16
range checking do not because it is also necessary to support the macro
of the same name which accepts simm32. The range checks for these occur in
the macro expansion.
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18437
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265019 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
ldc2/sdc2 now emit slightly worse diagnostics for MIPS-I. The problem
is that they don't trigger the custom parser because all the candidates
are disabled by feature bits. On all other subtargets, the diagnostics are
accurate but are subject to the usual issues of needing to report multiple
ways to correct the code (e.g. smaller offset, enable a CPU feature) but
only being able to report one error.
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18436
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265018 91177308-0d34-0410-b5e6-96231b3b80d8
Change isConsecutiveLoads to check that loads are non-volatile as this
is a requirement for any load merges. Propagate change to two callers.
Reviewers: RKSimon
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18546
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265013 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The bug was that microMIPS's [ls]w[lr]e instructions claimed to support a
12-bit offset when it is only 9-bit.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D18434
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265010 91177308-0d34-0410-b5e6-96231b3b80d8
PPC has a vector popcount, this lets the vectorizer use the correct cost
for it. Tweak X86 test to use an intrinsic that's actually scalarized (we
have a somewhat efficient lowering for vector popcount using SSE, the
cost model finds that now).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265005 91177308-0d34-0410-b5e6-96231b3b80d8
The rule for SMIN introduced in rL236202 doesn't work as advertised: the
check for Pred == ICmpInst::ICMP_SGT was missing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264996 91177308-0d34-0410-b5e6-96231b3b80d8
This way once we teach MatchBinaryOp to map more things into arithmetic,
the non-wrapping add recurrence construction would understand it too.
Right now MatchBinaryOp still only understands arithmetic, so this is
solely a code-reorganization change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264994 91177308-0d34-0410-b5e6-96231b3b80d8
Start fixing tests accordingly. There are still
about 35 failures before we can enable this check
in the IR verifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264990 91177308-0d34-0410-b5e6-96231b3b80d8
When dealing with complex<float>, and similar structures with two
single-precision floating-point numbers, especially when such things are being
passed around by value, we'll sometimes end up loading both float values by
extracting them from one 64-bit integer load. It looks like this:
t13: i64,ch = load<LD8[%ref.tmp]> t0, t6, undef:i64
t16: i64 = srl t13, Constant:i32<32>
t17: i32 = truncate t16
t18: f32 = bitcast t17
t19: i32 = truncate t13
t20: f32 = bitcast t19
The problem, especially before the P8 where those bitcasts aren't legal (and
get expanded via the stack), is that it would have been better to use two
floating-point loads directly. Here we add a target-specific DAGCombine to do
just that. In short, we turn:
ld 3, 0(5)
stw 3, -8(1)
rldicl 3, 3, 32, 32
stw 3, -4(1)
lfs 3, -4(1)
lfs 0, -8(1)
into:
lfs 3, 4(5)
lfs 0, 0(5)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264988 91177308-0d34-0410-b5e6-96231b3b80d8
