Andrea Di Biagio [Sat, 16 Aug 2014 00:29:44 +0000 (00:29 +0000)]
[DAGCombiner] Improve the folding of target independet shuffles to Undef.
When combining a pair of shuffle nodes, check if the combined shuffle mask is
trivially Undef. In case, immediately fold that pair of shuffles to Undef.
The lack of checks for undef masks was the root-cause of a poor-codegen bug
in the dag combiner.
Example:
%1 = shufflevector <4 x i32> %A, <4 x i32> %B, <4 x i32> <i32 4, i32 1, i32 1, i32 6>
%2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 0, i32 4, i32 1, i32 6>
%3 = shufflevector <4 x i32> %2, <4 x i32> undef, <4 x i32> <i32 1, i32 5, i32 3, i32 3>
Before this patch, on x86 (with -mcpu=corei7) we failed to fold the entire
sequence to Undef value and therefore we generated:
shufps $-123, %xmm1, $xmm0
pshufd $-46, %xmm0, %xmm0
With this patch, the entire shuffle sequence is folded to Undef and no
shuffles are generated in the output assembly.
Added new test cases to test 'combine-vec-shuffle-5.ll'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215797
91177308-0d34-0410-b5e6-
96231b3b80d8
Hal Finkel [Sat, 16 Aug 2014 00:17:05 +0000 (00:17 +0000)]
[PowerPC] Mark fixed-offset byvals as pointed-to by IR values
A byval object, even if allocated at a fixed offset (prescribed by the ABI) is
pointed to by IR values. Most fixed-offset stack objects are not pointed-to by
IR values, so the default is to assume this is not possible. However, we need
to override the default in this case (instruction scheduling can cause
miscompiles otherwise).
Fixes PR20280.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215795
91177308-0d34-0410-b5e6-
96231b3b80d8
Hal Finkel [Sat, 16 Aug 2014 00:17:02 +0000 (00:17 +0000)]
Make isAliased property for fixed-offset stack objects adjustable
We used to assume that any fixed-offset stack object was not aliased. This
meant that no IR value could point to the memory contained in such an object.
This is a reasonable default, but is not a universally-correct
target-independent fact. For example, on PowerPC (both Darwin and non-Darwin),
some byval arguments are allocated at fixed offsets by the ABI. These, however,
certainly can be pointed to by IR values. This change moves the 'isAliased'
logic out of FixedStackPseudoSourceValue and into MFI, and allows the isAliased
property to be overridden for fixed-offset objects.
This will be used by an upcoming commit to the PowerPC backend to fix PR20280.
No functionality change intended (the behavior of
FixedStackPseudoSourceValue::isAliased has been made more conservative for
callers that don't pass an MFI object, but I don't see any in-tree callers that
do that).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215794
91177308-0d34-0410-b5e6-
96231b3b80d8
Hal Finkel [Sat, 16 Aug 2014 00:16:29 +0000 (00:16 +0000)]
[PowerPC] Darwin byval arguments are not immutable
On PPC/Darwin, byval arguments occur at fixed stack offsets in the callee's
frame, but are not immutable -- the pointer value is directly available to the
higher-level code as the address of the argument, and the value of the byval
argument can be modified at the IR level.
This is necessary, but not sufficient, to fix PR20280. When PR20280 is fixed in
a follow-up commit, its test case will cover this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215793
91177308-0d34-0410-b5e6-
96231b3b80d8
Sean Silva [Fri, 15 Aug 2014 23:39:01 +0000 (23:39 +0000)]
Revert "[Support] Promote cl::StringSaver to a separate utility"
This reverts commit r215784 /
3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.
LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215790
91177308-0d34-0410-b5e6-
96231b3b80d8
Robin Morisset [Fri, 15 Aug 2014 23:36:00 +0000 (23:36 +0000)]
Get rid of dead code: SelectAtomic64 in X86ISelDAGtoDAG.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215789
91177308-0d34-0410-b5e6-
96231b3b80d8
Sean Silva [Fri, 15 Aug 2014 23:18:33 +0000 (23:18 +0000)]
[Support] Promote cl::StringSaver to a separate utility
This class is generally useful.
In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).
I've identified 2 other places in the
codebase that are open-coding this pattern:
memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)
I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.
Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215784
91177308-0d34-0410-b5e6-
96231b3b80d8
Robin Morisset [Fri, 15 Aug 2014 22:25:12 +0000 (22:25 +0000)]
Add two helper functions: isAtLeastAcquire, isAtLeastRelease
These methods are available on AtomicOrdering values, and will be used
in a later separate patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215779
91177308-0d34-0410-b5e6-
96231b3b80d8
Robin Morisset [Fri, 15 Aug 2014 22:17:28 +0000 (22:17 +0000)]
Fix typos in comments
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215777
91177308-0d34-0410-b5e6-
96231b3b80d8
Chad Rosier [Fri, 15 Aug 2014 21:38:16 +0000 (21:38 +0000)]
[AArch32] Add support for FP rounding operations for ARMv8/AArch32.
Phabricator Revision: http://reviews.llvm.org/D4935
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215772
91177308-0d34-0410-b5e6-
96231b3b80d8
Nick Kledzik [Fri, 15 Aug 2014 21:35:07 +0000 (21:35 +0000)]
[Option] Support MultiArg in --help
Currently, if you use a MultiArg<> option, then printing out the help/usage
message will cause an assert. This fixes getOptionHelpName() to work with
MultiArg Options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215770
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 20:17:08 +0000 (20:17 +0000)]
Set comdats when lazily linking functions.
We were setting the comdat when functions were copied in the initial pass, but
not when they were linked only when we found out that they are needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215765
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Fri, 15 Aug 2014 18:55:55 +0000 (18:55 +0000)]
[FastISel][AArch64] Fix a latent bug in floating-point materialization.
The floating-point value positive zero (+0.0) is a valid immedate value
according to isFPImmLegal. As a result AArch64 FastISel went ahead and
used the immediate version of fmov to materialize the constant.
The problem is that the immediate version of fmov cannot encode an imediate for
postive zero. Instead a fmov from the zero register was supposed to be used in
this case.
This fix adds handling for this special case and uses fmov from the zero
register to materialize a positive zero (negative zeroes go to the constant
pool).
There is no test case for this, because this code is currently dead. It will be
enabled in a future commit and I will add a test case in a separate commit
after that.
This fixes <rdar://problem/
18027157>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215753
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Fri, 15 Aug 2014 18:55:52 +0000 (18:55 +0000)]
Reapplying [FastISel][AArch64] Cleanup constant materialization code. NFCI.
Note: This reapplies r215582 without any modifications. The refactoring wasn't
responsible for the buildbot failures.
Original commit message:
Cleanup and prepare constant materialization code for future commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215752
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 18:42:22 +0000 (18:42 +0000)]
R600/SI: Move all fabs / fneg handling to patterns
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215749
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 18:42:18 +0000 (18:42 +0000)]
R600/SI: Use source modifiers for f64 fneg
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215748
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 18:42:15 +0000 (18:42 +0000)]
R600/SI: Use source modifier for f64 fabs
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215747
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 18:42:11 +0000 (18:42 +0000)]
R600/SI: Refactor fneg / fabs patterns
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215746
91177308-0d34-0410-b5e6-
96231b3b80d8
Reid Kleckner [Fri, 15 Aug 2014 18:03:58 +0000 (18:03 +0000)]
Fix the build with MSVC 2013 after new shuffle code
MSVC gives this awesome diagnostic:
..\lib\Target\X86\X86ISelLowering.cpp(7085) : error C2971: 'llvm::VariadicFunction1' : template parameter 'Func' : 'isShuffleEquivalentImpl' : a local variable cannot be used as a non-type argument
..\include\llvm/ADT/VariadicFunction.h(153) : see declaration of 'llvm::VariadicFunction1'
..\lib\Target\X86\X86ISelLowering.cpp(7061) : see declaration of 'isShuffleEquivalentImpl'
Using an anonymous namespace makes the problem go away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215744
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 17:49:05 +0000 (17:49 +0000)]
R600/SI: Fix offset folding in some cases with shifted pointers.
Ordinarily (shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2)
is only done if the add has one use. If the resulting constant
add can be folded into an addressing mode, force this to happen
for the pointer operand.
This ends up happening a lot because of how LDS objects are allocated.
Since the globals are allocated next to each other, acessing the first
element of the second object is directly indexed by a shifted pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215739
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 17:42:00 +0000 (17:42 +0000)]
[x86] Teach the new AVX v4f64 shuffle lowering to use UNPCK instructions
where applicable for blending.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215737
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Fri, 15 Aug 2014 17:36:30 +0000 (17:36 +0000)]
[FastISel] Remove an performance debugging assert.
As Jim pointed out this assert isn't really needed to test for correctness,
because the code right afterwards does the same check and falls-back to
SelectionDAG - as intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215735
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 17:30:25 +0000 (17:30 +0000)]
R600/SI: Add intrinsic for ldexp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215734
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Fri, 15 Aug 2014 17:23:20 +0000 (17:23 +0000)]
[FastISel][ARM] Fix unit test from r215682.
Thanks Jim for finding this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215733
91177308-0d34-0410-b5e6-
96231b3b80d8
Matt Arsenault [Fri, 15 Aug 2014 17:17:07 +0000 (17:17 +0000)]
R600/SI: Implement isLegalAddressingMode
The default assumes that a 16-bit signed offset is used.
LDS instruction use a 16-bit unsigned offset, so it wasn't
being used in some cases where it was assumed a negative offset
could be used.
More should be done here, but first isLegalAddressingMode needs
to gain an addressing mode argument. For now, copy most of the rest
of the default implementation with the immediate offset change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215732
91177308-0d34-0410-b5e6-
96231b3b80d8
Moritz Roth [Fri, 15 Aug 2014 17:00:30 +0000 (17:00 +0000)]
ARM: Fix and re-enable load/store optimizer for Thumb1.
In a previous iteration of the pass, we would try to compensate for
writeback by updating later instructions and/or inserting a SUBS to
reset the base register if necessary.
Since such a SUBS sets the condition flags it's not generally safe to do
this. For now, only merge LDR/STRs if there is no writeback to the base
register (LDM that loads into the base register) or the base register is
killed by one of the merged instructions. These cases are clear wins
both in terms of instruction count and performance.
Also add three new test cases, and update the existing ones accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215729
91177308-0d34-0410-b5e6-
96231b3b80d8
Moritz Roth [Fri, 15 Aug 2014 17:00:20 +0000 (17:00 +0000)]
ARM load/store optimizer: Compute BaseKill correctly.
This adds some code back that was deleted in r92053. The location of the
last merged memory operation needs to be kept up-to-date since MemOps
may be in a different order to the original instruction stream to
allow merging (since registers need to be in ascending order). Also
simplify the logic to determine BaseKill using findRegisterUseOperandIdx
to use an equivalent function call instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215728
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Fri, 15 Aug 2014 16:59:46 +0000 (16:59 +0000)]
[FastISel][ARM] Fix a think-o in my previous commit (r215682).
We actually need to return the register into which we materialized the constant
and not just "true" for success. This code is currently partially dead, that is
why it didn't trigger any failures yet. Once I change the order of the constant
materialization this code will be fully exercised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215727
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 15:46:38 +0000 (15:46 +0000)]
Introduce a helper to combine instruction metadata.
Replace the old code in GVN and BBVectorize with it. Update SimplifyCFG to use
it.
Patch by Björn Steinbrink!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215723
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 15:12:13 +0000 (15:12 +0000)]
Make EmitAbsValue an static helper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215721
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:58:22 +0000 (14:58 +0000)]
Delete dead code. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215720
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:43:02 +0000 (14:43 +0000)]
Make EmitDwarfSetLineAddr an static helper. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215718
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:31:47 +0000 (14:31 +0000)]
Make BuildSymbolDiff an static helper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215717
91177308-0d34-0410-b5e6-
96231b3b80d8
Amara Emerson [Fri, 15 Aug 2014 14:29:57 +0000 (14:29 +0000)]
[AArch64] Narrow arguments passed in wrong position on the stack in
big-endian mode.
Patch by Asiri Rathnayake.
Differential Revision: http://reviews.llvm.org/D4922
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215716
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:24:41 +0000 (14:24 +0000)]
Make ForceExpAbs an static helper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215715
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:20:32 +0000 (14:20 +0000)]
Add a helper to MCExpr for when an expression is know to be absolute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215713
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 14:01:07 +0000 (14:01 +0000)]
Remove HasLEB128.
We already require CFI, so it should be safe to require .leb128 and .uleb128.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215712
91177308-0d34-0410-b5e6-
96231b3b80d8
Bill Schmidt [Fri, 15 Aug 2014 13:51:57 +0000 (13:51 +0000)]
[PPC64] Add test case for r215685.
I had deferred adding this test case until I could get it down to a
reasonable size. That's done now.
Thanks,
Bill
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215711
91177308-0d34-0410-b5e6-
96231b3b80d8
Benjamin Kramer [Fri, 15 Aug 2014 11:05:45 +0000 (11:05 +0000)]
PPC: Clean up pointer casting, no functionality change.
Silences GCC's -Wcast-qual.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215703
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 11:01:40 +0000 (11:01 +0000)]
[x86] Add the initial skeleton of type-based dispatch for AVX vectors in
the new shuffle lowering and an implementation for v4 shuffles.
This allows us to handle non-half-crossing shuffles directly for v4
shuffles, both integer and floating point. This currently misses places
where we could perform the blend via UNPCK instructions, but otherwise
generates equally good or better code for the test cases included to the
existing vector shuffle lowering. There are a few cases that are
entertainingly better. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215702
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 11:01:37 +0000 (11:01 +0000)]
[x86] Teach the instruction printer to decode immediate operands to
BLENDPS, BLENDPD, and PBLENDW instructions into pretty shuffle comments.
These will be used in my next commit as part of test cases for AVX
shuffles which can directly use blend in more places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215701
91177308-0d34-0410-b5e6-
96231b3b80d8
Tim Northover [Fri, 15 Aug 2014 10:47:12 +0000 (10:47 +0000)]
ARM: implement MRS/MSR (banked reg) system instructions.
These are system-only instructions for CPUs with virtualization
extensions, allowing a hypervisor easy access to all of the various
different AArch32 registers.
rdar://problem/
17861345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215700
91177308-0d34-0410-b5e6-
96231b3b80d8
Erik Verbruggen [Fri, 15 Aug 2014 10:33:03 +0000 (10:33 +0000)]
Remove testcase from README which we didn't get. We do get it now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215699
91177308-0d34-0410-b5e6-
96231b3b80d8
Vladimir Medic [Fri, 15 Aug 2014 09:29:30 +0000 (09:29 +0000)]
Current implementation of c.cond.fmt instructions only accept default cc0 register. This patch enables the instruction to accept other fcc registers. The aliases with default fcc0 registers are also defined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215698
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 07:41:57 +0000 (07:41 +0000)]
[x86] Remove the duplicated code for testing whether we can widen the
elements of a shuffle mask and simplify how it works. No functionality
changed now that the bug that was here has been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215696
91177308-0d34-0410-b5e6-
96231b3b80d8
Eric Fiselier [Fri, 15 Aug 2014 05:54:19 +0000 (05:54 +0000)]
[LIT]Correct name of global lit configuration object to be lit_config (not lit).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215695
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 03:54:49 +0000 (03:54 +0000)]
[x86] Fix the very broken formation of vpunpck instructions in the
target-specific shuffl DAG combines.
We were recognizing the paired shuffles backwards. This code needs to be
replaced anyways as we have the same functionality elsewhere, but I'll
do the refactoring in a follow-up, this is the minimal fix to the
behavior.
In addition to fixing miscompiles with the new vector shuffle lowering,
it also causes the canonicalization to kick in much better, selecting
the smaller encoding variants in lots of places in the new AVX path.
This still isn't quite ideal as we don't need both the shufpd and the
punpck instructions, but that'll get fixed in a follow-up patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215690
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 03:07:13 +0000 (03:07 +0000)]
Don't print comments to an object streamer :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215689
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Fri, 15 Aug 2014 02:51:31 +0000 (02:51 +0000)]
EmitAbsValue is the same as EmitValue on non-darwin. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215688
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Fri, 15 Aug 2014 02:43:18 +0000 (02:43 +0000)]
[x86] Fix PR20540 where the x86 shuffle DAG combiner had completely
broken logic for merging shuffle masks in the face of SM_SentinelZero
mask operands.
While these are '-1' they don't mean 'undef' the way '-1' means in the
pre-legalized shuffle masks. Instead, they mean that the shuffle
operation is forcibly zeroing that lane. Reflect this and explicitly
handle it in a bunch of places. In one place the effect is equivalent
but much more clear. In the rest it was really weirdly broken.
Also, rewrite the entire merging thing to be a more directy operation
with a single loop and just doing math to map the indices through the
various masks.
Also add a bunch of asserts to try to make in extremely clear what the
different masks can possibly look like.
Finally, add some comments to clarify that we're merging shuffle masks
*up* here rather than *down* as we do everywhere else, and thus the
logic is quite confusing.
Thanks to several different people for sending test cases, and for
Robert Khasanov for an initial attempt at fixing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215687
91177308-0d34-0410-b5e6-
96231b3b80d8
Bill Schmidt [Fri, 15 Aug 2014 01:25:26 +0000 (01:25 +0000)]
[PPC64] Add missing dependency on X2 to LDinto_toc.
The LDinto_toc pattern has been part of 64-bit PowerPC for a long
time, and represents loading from a memory location into the TOC
register (X2). However, this pattern doesn't explicitly record that
it modifies that register. This patch adds the missing dependency.
It was very surprising to me that this has never shown up as a problem
in the past, and that we only saw this problem recently in a single
scenario when building a self-hosted clang. It turns out that in most
cases we have another dependency present that keeps the LDinto_toc
instruction tied in place. LDinto_toc is used for TOC restore
following a call site, so this is a typical sequence:
BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
LDinto_toc 24, %X1
ADJCALLSTACKUP 96, 0, %R1<imp-def>, %R1<imp-use>
Because the LDinto_toc is inserted prior to the ADJCALLSTACKUP, there
is a natural anti-dependency between the two that keeps it in place.
Therefore we don't usually see a problem. However, in one particular
case, one call is followed immediately by another call, and the second
call requires a parameter that is a TOC-relative address. This is the
code sequence:
BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
LDinto_toc 24, %X1
ADJCALLSTACKUP 96, 0, %R1<imp-def>, %R1<imp-use>
ADJCALLSTACKDOWN 96, %R1<imp-def>, %R1<imp-use>
%vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
%vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39
Note that the back-to-back stack adjustments are the same size! The
back end is smart enough to recognize this and optimize them away:
BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
LDinto_toc 24, %X1
%vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
%vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39
Now there is nothing to prevent the ADDIStocHA instruction from moving
ahead of the LDinto_toc instruction, and because of the longest-path
heuristic, this is what happens.
With the accompanying patch, %X2 is represented as an implicit def:
BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
LDinto_toc 24, %X1, %X2<imp-def,dead>
ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<imp-use>
ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use>
%vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
%vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39
So now when the two stack adjustments are removed, ADDIStocHA is
prevented from being moved above LDinto_toc.
I have not yet created a test case for this, because the original
failure occurs on a relatively large function that needs reduction.
However, this is a fairly serious bug, despite its infrequency, and I
wanted to get this patch onto the list as soon as possible so that it
can be considered for a 3.5 backport. I'll work on whittling down a
test case.
Have we missed the boat for 3.5 at this point?
Thanks,
Bill
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215685
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Thu, 14 Aug 2014 23:29:49 +0000 (23:29 +0000)]
[FastISel][ARM] Fall-back to constant pool loads when materializing an i32 constant.
FastEmit_i won't always succeed to materialize an i32 constant and just fail.
This would trigger a fall-back to SelectionDAG, which is really not necessary.
This fix will first fall-back to a constant pool load to materialize the constant
before giving up for good.
This fixes <rdar://problem/
18022633>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215682
91177308-0d34-0410-b5e6-
96231b3b80d8
Hal Finkel [Thu, 14 Aug 2014 21:09:37 +0000 (21:09 +0000)]
Copy noalias metadata from call sites to inlined instructions
When a call site with noalias metadata is inlined, that metadata can be
propagated directly to the inlined instructions (only those that might access
memory because it is not useful on the others). Prior to inlining, the noalias
metadata could express that a call would not alias with some other memory
access, which implies that no instruction within that called function would
alias. By propagating the metadata to the inlined instructions, we preserve
that knowledge.
This should complete the enhancements requested in PR20500.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215676
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Thu, 14 Aug 2014 19:56:28 +0000 (19:56 +0000)]
Revert several FastISel commits to track down a buildbot error.
This reverts:
r215595 "[FastISel][X86] Add large code model support for materializing floating-point constants."
r215594 "[FastISel][X86] Use XOR to materialize the "0" value."
r215593 "[FastISel][X86] Emit more efficient instructions for integer constant materialization."
r215591 "[FastISel][AArch64] Make use of the zero register when possible."
r215588 "[FastISel] Let the target decide first if it wants to materialize a constant."
r215582 "[FastISel][AArch64] Cleanup constant materialization code. NFCI."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215673
91177308-0d34-0410-b5e6-
96231b3b80d8
Duncan P. N. Exon Smith [Thu, 14 Aug 2014 17:18:26 +0000 (17:18 +0000)]
Fix whitespace error from r215279, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215667
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:33 +0000 (17:13 +0000)]
[AVX512] Add test for FMA masking instrinsics
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215665
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:30 +0000 (17:13 +0000)]
[AVX512] Switch FMA intrinsics to the masking version
This does the renaming and updates the lowering logic.
Part of <rdar://problem/
17688758>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215664
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:27 +0000 (17:13 +0000)]
[X86] Break out logic to map FMA Intrinsic number to Opcode
No functional change. Will be used to lower AVX512 masking FMA intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215663
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:26 +0000 (17:13 +0000)]
[AVX512] Add enum for the static rounding types
No functional change. This will be used by the new FMA intrinsic lowering
code.
We can probably add NO_EXC here as well, I am just not too familiar with this
part of AVX512 yet. We can add that later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215662
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:24 +0000 (17:13 +0000)]
[AVX512] Break out the logic to lower masking intrinsics
No functional change. This will be used by the FMA intrinsic lowering as well
and hopefully many more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215661
91177308-0d34-0410-b5e6-
96231b3b80d8
Adam Nemet [Thu, 14 Aug 2014 17:13:19 +0000 (17:13 +0000)]
[AVX512] Add masking variant for the FMA instructions
This change further evolves the base class AVX512_masking in order to make it
suitable for the masking variants of the FMA instructions.
Besides AVX512_masking there is now a new base class that instructions
including FMAs can use: AVX512_masking_3src. With three-source (destructive)
instructions one of the sources is already tied to the destination. This
difference from AVX512_masking is captured by this new class. The common bits
between _masking and _masking_3src are broken out into a new super class
called AVX512_masking_common.
As with valign, there is some corresponding restructuring of the underlying
format classes. The idea is the same we want to derive from two classes
essentially: one providing the format bits and another format-independent
multiclass supplying the various masking and non-masking instruction variants.
Existing fma tests in avx512-fma*.ll provide coverage here for the non-masking
variants. For masking, the next patches in the series will add intrinsics and
intrinsic tests.
For AVX512_masking_3src to work, the (ins ...) dag has to be passed *without*
the leading source operand that is tied to dst ($src1). This is necessary to
properly construct the (ins ...) for the different variants. For the record,
I did check that if $src is mistakenly included, you do get a fairly intuitive
error message from the tablegen backend.
Part of <rdar://problem/
17688758>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215660
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Thu, 14 Aug 2014 17:10:54 +0000 (17:10 +0000)]
Revert "[FastISel][AArch64] Add support for more addressing modes."
This reverts commits r215597, because it might have broken the build bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215659
91177308-0d34-0410-b5e6-
96231b3b80d8
Hal Finkel [Thu, 14 Aug 2014 16:44:03 +0000 (16:44 +0000)]
Add noalias metadata for general calls (not just memory intrinsics) during inlining
When preserving noalias function parameter attributes by adding noalias
metadata in the inliner, we should do this for general function calls (not just
memory intrinsics). The logic is very similar to what already existed (except
that we want to add this metadata even for functions taking no relevant
parameters). This metadata can be used by ModRef queries in the caller after
inlining.
This addresses the first part of PR20500. Adding noalias metadata during
inlining is still turned off by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215657
91177308-0d34-0410-b5e6-
96231b3b80d8
Moritz Roth [Thu, 14 Aug 2014 16:20:50 +0000 (16:20 +0000)]
Testing commit access.
Remove a trailing whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215653
91177308-0d34-0410-b5e6-
96231b3b80d8
Chad Rosier [Thu, 14 Aug 2014 15:23:01 +0000 (15:23 +0000)]
[Reassociation] Add support for reassociation with unsafe algebra.
Vector instructions are (still) not supported for either integer or floating
point. Hopefully, that work will be landed shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215647
91177308-0d34-0410-b5e6-
96231b3b80d8
Sanjay Patel [Thu, 14 Aug 2014 15:15:28 +0000 (15:15 +0000)]
optimize vector fneg of bitcasted integer value
This patch allows a vector fneg of a bitcasted integer value to be optimized in the same way that we already optimize a scalar fneg. If the integer variable is a constant, we can precompute the result and not require any logic ops.
This patch is very similar to a fabs patch committed at r214892.
Differential Revision: http://reviews.llvm.org/D4852
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215646
91177308-0d34-0410-b5e6-
96231b3b80d8
Rafael Espindola [Thu, 14 Aug 2014 15:15:09 +0000 (15:15 +0000)]
Delete support for AuroraUX.
auroraux.org is not resolving.
I will add this to the release notes as soon as I figure out where to put the
3.6 release notes :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215645
91177308-0d34-0410-b5e6-
96231b3b80d8
Aaron Ballman [Thu, 14 Aug 2014 13:53:19 +0000 (13:53 +0000)]
Silencing some -Wcast-qual warnings and removing some C-style casts at the same time. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215643
91177308-0d34-0410-b5e6-
96231b3b80d8
Aaron Ballman [Thu, 14 Aug 2014 13:43:57 +0000 (13:43 +0000)]
Silencing an MSVC C4334 warning ('<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)). NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215642
91177308-0d34-0410-b5e6-
96231b3b80d8
Toma Tabacu [Thu, 14 Aug 2014 13:10:48 +0000 (13:10 +0000)]
[mips] Improve robustness of some tests.
Summary:
This is done by removing some hardcoded registers like $at or expecting a single digit register to be selected.
Contains work done by Matheus Almeida.
Reviewers: matheusalmeida, dsanders
Reviewed By: dsanders
Subscribers: tomatabacu
Differential Revision: http://reviews.llvm.org/D4227
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215640
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Thu, 14 Aug 2014 12:13:59 +0000 (12:13 +0000)]
[x86] Begin stubbing out the AVX support in the new vector shuffle
lowering scheme.
Currently, this just directly bails to the fallback path of splitting
the 256-bit vector into two 128-bit vectors, operating there, and then
joining the results back together. While the results are far from
perfect, they are *shockingly* good for what we're doing here. I'll be
layering the rest of the functionality on top of this piece by piece and
updating tests as I go.
Note that 256-bit vectors in this mode are still somewhat WIP. While
I think the code paths that I'm adding here are clean and good-to-go,
there are still a lot of 128-bit assumptions that I'll need to stomp out
as I march through the functional spread here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215637
91177308-0d34-0410-b5e6-
96231b3b80d8
Zoran Jovanovic [Thu, 14 Aug 2014 12:09:10 +0000 (12:09 +0000)]
[mips][microMIPS] MicroMIPS Compact Branch Instructions BEQZC and BNEZC
Differential Revision: http://reviews.llvm.org/D3545
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215636
91177308-0d34-0410-b5e6-
96231b3b80d8
Dan Liew [Thu, 14 Aug 2014 11:57:16 +0000 (11:57 +0000)]
Make message about building sphinx documentation with CMake more
informative by stating where the output is going.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215635
91177308-0d34-0410-b5e6-
96231b3b80d8
Dan Liew [Thu, 14 Aug 2014 11:57:13 +0000 (11:57 +0000)]
Add SPHINX_WARNINGS_AS_ERRORS CMake option to allow warnings to not be
treated as errors (which is still the default). This is useful when
working on documentation that has existing errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215634
91177308-0d34-0410-b5e6-
96231b3b80d8
Toma Tabacu [Thu, 14 Aug 2014 10:29:17 +0000 (10:29 +0000)]
[mips] Add assembler support for the "la $reg,symbol" pseudo-instruction.
Summary:
This pseudo-instruction allows the programmer to load an address from a symbolic expression into a register.
Patch by David Chisnall.
His work was sponsored by: DARPA, AFRL
I've made some minor changes to the original, such as improving the formatting and adding some comments, and I've also added a test case.
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4808
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215630
91177308-0d34-0410-b5e6-
96231b3b80d8
Daniel Sanders [Thu, 14 Aug 2014 09:18:14 +0000 (09:18 +0000)]
[mips] Rename [gs]etCanHaveModuleDir to more natural names
Summary:
getCanHaveModuleDir() is renamed to isModuleDirectiveAllowed(), and
setCanHaveModuleDir() is renamed to forbidModuleDirective() since it is only
ever given a false argument.
Reviewers: vmedic
Reviewed By: vmedic
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4885
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215628
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Thu, 14 Aug 2014 08:18:34 +0000 (08:18 +0000)]
[SDAG] Fix a bug in the DAG combiner where we would fail to return the
input node after manually adding it to the worklist and using CombineTo.
Once we use CombineTo the input node may have been deleted. Despite this
being *completely confusing* and somewhat broken, the only way to
"correctly" return from a DAG combine after potentially deleting the
input node is to return *that exact node*....
But really, this code should just never have used CombineTo. It won't do
what it wants (returning the node as mentioned above just causes the
combine to infloop). The correct way to combine away a casted load to
a load of the correct type is to RAUW the chain directly and then return
the loaded value to replace the actual value node.
I managed to find this with the vector shuffle fuzzer even though it
clearly has nothing at all to do with vector shuffles and rather those
happen to trigger a load of a constant pool that hits this combine *just
right*. I've included the test as it is small and a nice stress test
that the infrastructure isn't asserting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215622
91177308-0d34-0410-b5e6-
96231b3b80d8
David Majnemer [Thu, 14 Aug 2014 06:46:25 +0000 (06:46 +0000)]
InstCombine: ((A | ~B) ^ (~A | B)) to A ^ B
Proof using CVC3 follows:
$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR((A | ~B),(~A |B)) = BVXOR(A,B);
$ cvc3 t.cvc
Valid.
Patch by Mayur Pandey!
Differential Revision: http://reviews.llvm.org/D4883
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215621
91177308-0d34-0410-b5e6-
96231b3b80d8
David Majnemer [Thu, 14 Aug 2014 06:44:51 +0000 (06:44 +0000)]
AArch64: Silence warning in AArch64FastISel
GCC was emitting a signed vs unsigned comparison warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215620
91177308-0d34-0410-b5e6-
96231b3b80d8
David Majnemer [Thu, 14 Aug 2014 06:41:38 +0000 (06:41 +0000)]
Added InstCombine Transform for ((B | C) & A) | B -> B | (A & C)
Transform ((B | C) & A) | B --> B | (A & C)
Link: http://rise4fun.com/Z3/hP6p
Patch by Sonam Kumari!
Differential Revision: http://reviews.llvm.org/D4865
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215619
91177308-0d34-0410-b5e6-
96231b3b80d8
Saleem Abdulrasool [Thu, 14 Aug 2014 02:51:43 +0000 (02:51 +0000)]
MC: AsmLexer: handle multi-character CommentStrings correctly
As X86MCAsmInfoDarwin uses '##' as CommentString although a single '#' starts a
comment a workaround for this special case is added.
Fixes divisions in constant expressions for the AArch64 assembler and other
targets which use '//' as CommentString.
Patch by Janne Grunau!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215615
91177308-0d34-0410-b5e6-
96231b3b80d8
Lang Hames [Thu, 14 Aug 2014 02:38:20 +0000 (02:38 +0000)]
[MCJIT] Support DisableSymbolSearching and InstallLazyFunctionCreator in MCJIT.
Patch by Anthony Pesch. Thanks Anthony!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215613
91177308-0d34-0410-b5e6-
96231b3b80d8
Chandler Carruth [Thu, 14 Aug 2014 01:07:37 +0000 (01:07 +0000)]
[SDAG] Fix a case where we would iteratively legalize a node during
combining by replacing it with something else but not re-process the
node afterward to remove it.
In a truly remarkable stroke of bad luck, this would (in the test case
attached) end up getting some other node combined into it without ever
getting re-processed. By adding it back on to the worklist, in addition
to deleting the dead nodes more quickly we also ensure that if it
*stops* being dead for any reason it makes it back through the
legalizer. Without this, the test case will end up failing during
instruction selection due to an and node with a type we don't have an
instruction pattern for.
It took many million runs of the shuffle fuzz tester to find this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215611
91177308-0d34-0410-b5e6-
96231b3b80d8
Michael J. Spencer [Thu, 14 Aug 2014 00:51:47 +0000 (00:51 +0000)]
Remove llvm_headers_do_not_build for the benefit of XCode and Visual Studio users.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215610
91177308-0d34-0410-b5e6-
96231b3b80d8
Quentin Colombet [Wed, 13 Aug 2014 23:49:24 +0000 (23:49 +0000)]
[X86] Fix the value of the low mask for the lowering of MUL_LOHI for v4i32.
Found by code inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215604
91177308-0d34-0410-b5e6-
96231b3b80d8
Akira Hatanaka [Wed, 13 Aug 2014 23:23:58 +0000 (23:23 +0000)]
[AArch64, fast-isel] Fall back to SelectionDAG to select tail calls.
Certain functions such as objc_autoreleaseReturnValue have to be called as
tail-calls even at -O0. Since normal fast-isel doesn't emit calls as tail calls,
we have to fall back to SelectionDAG to select calls that are marked as tail.
<rdar://problem/
17991614>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215600
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:53:29 +0000 (22:53 +0000)]
[FastISel][AArch64] Add support for more addressing modes.
FastISel didn't take much advantage of the different addressing modes available
to it on AArch64. This commit allows the ComputeAddress method to recognize more
addressing modes that allows shifts and sign-/zero-extensions to be folded into
the memory operation itself.
For Example:
lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3]
ldr x0, [x0, x1]
sxtw x1, w1
lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3]
ldr x0, [x0, x1]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215597
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:25:35 +0000 (22:25 +0000)]
[FastISel][X86] Add large code model support for materializing floating-point constants.
In the large code model for X86 floating-point constants are placed in the
constant pool and materialized by loading from it. Since the constant pool
could be far away, a PC relative load might not work. Therefore we first
materialize the address of the constant pool with a movabsq and then load
from there the floating-point value.
Fixes <rdar://problem/
17674628>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215595
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:22:17 +0000 (22:22 +0000)]
[FastISel][X86] Use XOR to materialize the "0" value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215594
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:18:11 +0000 (22:18 +0000)]
[FastISel][X86] Emit more efficient instructions for integer constant materialization.
This mostly affects the i64 value type, which always resulted in an 15byte
mobavsq instruction to materialize any constant. The custom code checks the
value of the immediate and tries to use a different and smaller mov
instruction when possible.
This fixes <rdar://problem/
17420988>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215593
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:13:14 +0000 (22:13 +0000)]
[FastISel][AArch64] Make use of the zero register when possible.
This change materializes now the value "0" from the zero register.
The zero register can be folded by several instruction, so no
materialization is need at all.
Fixes <rdar://problem/
17924413>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215591
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:08:02 +0000 (22:08 +0000)]
[FastISel] Let the target decide first if it wants to materialize a constant.
This changes the order in which FastISel tries to materialize a constant.
Originally it would try to use a simple target-independent approach, which
can lead to the generation of inefficient code.
On X86 this would result in the use of movabsq to materialize any 64bit
integer constant - even for simple and small values such as 0 and 1. Also
some very funny floating-point materialization could be observed too.
On AArch64 it would materialize the constant 0 in a register even the
architecture has an actual "zero" register.
On ARM it would generate unnecessary mov instructions or not use mvn.
This change simply changes the order and always asks the target first if it
likes to materialize the constant. This doesn't fix all the issues
mentioned above, but it enables the targets to implement such
optimizations.
Related to <rdar://problem/
17420988>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215588
91177308-0d34-0410-b5e6-
96231b3b80d8
Gerolf Hoflehner [Wed, 13 Aug 2014 22:07:36 +0000 (22:07 +0000)]
[MachineCombiner] Removal of dangling DBG_VALUES after combining [20598]
This is a cleaner solution to the problem described in r215431.
When instructions are combined a dangling DBG_VALUE is removed.
This resolves bug 20598.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215587
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 22:01:55 +0000 (22:01 +0000)]
[FastISel][X86] Refactor constant materialization. NFCI.
Split the constant materialization code into three separate helper functions for
Integer-, Floating-Point-, and GlobalValue-Constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215586
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 21:42:19 +0000 (21:42 +0000)]
[FastISel][ARM] Use MOVT/MOVW if the subtarget requests it.
This change is also in preparation for a future change to make sure that
the constant materialization uses MOVT/MOVW when available and not a load
from the constant pool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215584
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 21:39:18 +0000 (21:39 +0000)]
[FastISel][ARM] Fix a bug in the integer materialization code.
getRegClassFor returns the incorrect register class when in Thumb2 mode.
This fix simply manually selects the register class as in the code just a few
lines above.
There is no test case for this code, because the code is currently
unreachable. This will be changed in a future commit and existing test
cases will exercise this code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215583
91177308-0d34-0410-b5e6-
96231b3b80d8
Juergen Ributzka [Wed, 13 Aug 2014 21:34:04 +0000 (21:34 +0000)]
[FastISel][AArch64] Cleanup constant materialization code. NFCI.
Cleanup and prepare constant materialization code for future commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215582
91177308-0d34-0410-b5e6-
96231b3b80d8
Gerolf Hoflehner [Wed, 13 Aug 2014 21:15:23 +0000 (21:15 +0000)]
[Cleanup] Utility function to erase instruction and mark DBG_Values
New function to erase a machine instruction and mark DBG_VALUE
for removal. A DBG_VALUE is marked for removal when it references
an operand defined in the instruction.
Use the new function to cleanup code in dead machine instruction
removal pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215580
91177308-0d34-0410-b5e6-
96231b3b80d8
Quentin Colombet [Wed, 13 Aug 2014 21:00:07 +0000 (21:00 +0000)]
[MachineDominatorTree] Provide a method to inform a MachineDominatorTree that a
critical edge has been split. The MachineDominatorTree will when lazy update the
underlying dominance properties when require.
** Context **
This is a follow-up of r215410.
Each time a critical edge is split this invalidates the dominator tree
information. Thus, subsequent queries of that interface will be slow until the
underlying information is actually recomputed (costly).
** Problem **
Prior to this patch, splitting a critical edge needed to query the dominator
tree to update the dominator information.
Therefore, splitting a bunch of critical edges will likely produce poor
performance as each query to the dominator tree will use the slow query path.
This happens a lot in passes like MachineSink and PHIElimination.
** Proposed Solution **
Splitting a critical edge is a local modification of the CFG. Moreover, as soon
as a critical edge is split, it is not critical anymore and thus cannot be a
candidate for critical edge splitting anymore. In other words, the predecessor
and successor of a basic block inserted on a critical edge cannot be inserted by
critical edge splitting.
Using these observations, we can pile up the splitting of critical edge and
apply then at once before updating the DT information.
The core of this patch moves the update of the MachineDominatorTree information
from MachineBasicBlock::SplitCriticalEdge to a lazy MachineDominatorTree.
** Performance **
Thanks to this patch, the motivating example compiles in 4- minutes instead of
6+ minutes. No test case added as the motivating example as nothing special but
being huge!
The binaries are strictly identical for all the llvm test-suite + SPECs with and
without this patch for both Os and O3.
Regarding compile time, I observed only noise, although on average I saw a
small improvement.
<rdar://problem/
17894619>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215576
91177308-0d34-0410-b5e6-
96231b3b80d8
Benjamin Kramer [Wed, 13 Aug 2014 20:41:26 +0000 (20:41 +0000)]
Fix (re-)creation of unittest lit.site.cfg for clang-tools-extra.
This has been hiding really well. Hopefully brings the builders suffering from
outdated lit.site.cfg files back to life.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215575
91177308-0d34-0410-b5e6-
96231b3b80d8