Only single and double FP immediates are correctly printed by
MachineInstr::print() during debug output. Half float type goes to
APFloat::convertToDouble() and hits assertion it is not a double
semantics. This diff prints half machine operands correctly.
This cannot currently be hit by any in-tree target.
Patch by Stanislav Mekhanoshin
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259857 91177308-0d34-0410-b5e6-96231b3b80d8
We don't currently have many tests that deal with operations on multiple
local MemoryLocations. This new test helps out a bit in that regard.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259854 91177308-0d34-0410-b5e6-96231b3b80d8
Summary computation is not just for instrumented profiling and so I have moved
the ProfileSummary class to ProfileCommon.h (named so to allow code unrelated
to summary but common to instrumented and sampled profiling to be placed there)
Differential Revision: http://reviews.llvm.org/D16661
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259846 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This basically add an echo test case in C. The support is limited right now, but full support would just be too much to review at once.
The echo test case simply get a module as input and try to output the same exact module. This allow to check the both reading and writing API are working as expected.
I want to improve this test over time to support more and more of the API, in order to improve coverage (coverage is quite poor right now).
Test Plan: Run the test.
Reviewers: chandlerc, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10725
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259844 91177308-0d34-0410-b5e6-96231b3b80d8
Using the load immediate only when the immediate (whether signed or unsigned)
can fit in a 16-bit signed field. Namely, from -32768 to 32767 for signed and
0 to 65535 for unsigned. This patch also ensures that we sign-extend under the
right conditions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259840 91177308-0d34-0410-b5e6-96231b3b80d8
This only impacts the creation of pre-/post-index instructions. The bound was
set high enough such that it did not change code generation for SPEC200X.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259828 91177308-0d34-0410-b5e6-96231b3b80d8
This is the right location for platform-specific files.
On some distributions (e. g. Exherbo), a package can be installed for several
architectures in parallel, but the architecture-independent files are shared.
Therefore, we must not install architecture-dependent files (like the CMake
config and export files) to share/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259821 91177308-0d34-0410-b5e6-96231b3b80d8
Choose between MOVD/MOVSS and MOVQ/MOVSD depending on the target vector type.
This has a lot fewer test changes than trying to add this to X86InstrInfo::setExecutionDomain.....
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259816 91177308-0d34-0410-b5e6-96231b3b80d8
When SCEV expansion tries to reuse an existing value, it is needed to ensure
that using the Value at the InsertPt will not break LCSSA. The fix adds a
check that InsertPt is either inside the candidate Value's parent loop, or
the candidate Value's parent loop is nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259815 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows the mixing of scaled and unscaled load/stores to form
load/store pairs.
PR24465
http://reviews.llvm.org/D12116
Many thanks to Ahmed and Michael for fixes and code review.
This is a reapplication of r246769 and r259790. The tramp3d failure was caused
by an incorrect refactoring in the patch. Specifically, we weren't always
properly clearing the SExtIdx flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259812 91177308-0d34-0410-b5e6-96231b3b80d8
During instruction selection, the AArch64 backend can recognise the
following pattern and generate an [U|S]MADDL instruction, i.e. a
multiply of two 32-bit operands with a 64-bit result:
(mul (sext i32), (sext i32))
However, when one of the operands is constant, the sign extension
gets folded into the constant in SelectionDAG::getNode(). This means
that the instruction selection sees this:
(mul (sext i32), i64)
...which doesn't match the pattern. Sign-extension and 64-bit
multiply instructions are generated, which are slower than one 32-bit
multiply.
Add a pattern to match this and generate the correct instruction, for
both signed and unsigned multiplies.
Patch by Chris Diamand!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259800 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the lit bug that enabled this "feature" (empty triple is substring
of all possible target triples) and change the two outliers to use the
documented * syntax.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259799 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to review:
http://reviews.llvm.org/D16847
There are some files in glibc that use the output operand modifier even though
it was deprecated in GCC. This patch just adds support for it to prevent issues
with such files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259798 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows the mixing of scaled and unscaled load/stores to form
load/store pairs.
PR24465
http://reviews.llvm.org/D12116
Many thanks to Ahmed and Michael for fixes and code review.
This is a reapplication of r246769, which was reverted in r246782 due to a
test-suite failure. I'm unable to reproduce the issue at this time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259790 91177308-0d34-0410-b5e6-96231b3b80d8
This adds -DLLVM_ENABLE_LTO, rather than forcing people to manually
add -flto to the various _FLAGS variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259766 91177308-0d34-0410-b5e6-96231b3b80d8
Current SCEV expansion will expand SCEV as a sequence of operations
and doesn't utilize the value already existed. This will introduce
redundent computation which may not be cleaned up throughly by
following optimizations.
This patch introduces an ExprValueMap which is a map from SCEV to the
set of equal values with the same SCEV. When a SCEV is expanded, the
set of values is checked and reused whenever possible before generating
a sequence of operations.
The original commit triggered regressions in Polly tests. The regressions
exposed two problems which have been fixed in current version.
1. Polly will generate a new function based on the old one. To generate an
instruction for the new function, it builds SCEV for the old instruction,
applies some tranformation on the SCEV generated, then expands the transformed
SCEV and insert the expanded value into new function. Because SCEV expansion
may reuse value cached in ExprValueMap, the value in old function may be
inserted into new function, which is wrong.
In SCEVExpander::expand, there is a logic to check the cached value to
be used should dominate the insertion point. However, for the above
case, the check always passes. That is because the insertion point is
in a new function, which is unreachable from the old function. However
for unreachable node, DominatorTreeBase::dominates thinks it will be
dominated by any other node.
The fix is to simply add a check that the cached value to be used in
expansion should be in the same function as the insertion point instruction.
2. When the SCEV is of scConstant type, expanding it directly is cheaper than
reusing a normal value cached. Although in the cached value set in ExprValueMap,
there is a Constant type value, but it is not easy to find it out -- the cached
Value set is not sorted according to the potential cost. Existing reuse logic
in SCEVExpander::expand simply chooses the first legal element from the cached
value set.
The fix is that when the SCEV is of scConstant type, don't try the reuse
logic. simply expand it.
Differential Revision: http://reviews.llvm.org/D12090
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259736 91177308-0d34-0410-b5e6-96231b3b80d8
enabled): ensure that we do not invoke the sized deallocator for MemoryBuffer
subclasses that have tail-allocated data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259735 91177308-0d34-0410-b5e6-96231b3b80d8
D16251)
Summary:
This is a simpler fix to the problem than the dominator approach in
http://reviews.llvm.org/D16251. It adds only values into the gather() while loop
that have been seen before.
The actual endless loop is in the constant compare gather() routine in
Utils/SimplifyCFG.cpp. The same value ret.0.off0.i is pushed back into the
queue:
%.ret.0.off0.i = or i1 %.ret.0.off0.i, %cmp10.i
Here is what happens at the IR level:
for.cond.i: ; preds = %if.end6.i,
%if.end.i54
%ix.0.i = phi i32 [ 0, %if.end.i54 ], [ %inc.i55, %if.end6.i ]
%ret.0.off0.i = phi i1 [false, %if.end.i54], [%.ret.0.off0.i, %if.end6.i] <<<
%cmp2.i = icmp ult i32 %ix.0.i, %11
br i1 %cmp2.i, label %for.body.i, label %LBJ_TmpSimpleNeedExt.exit
if.end6.i: ; preds = %for.body.i
%cmp10.i = icmp ugt i32 %conv.i, %add9.i
%.ret.0.off0.i = or i1 %ret.0.off0.i, %cmp10.i <<<
When if.end.i54 gets eliminated which removes the definition of ret.0.off0.i.
The result is the expression %.ret.0.off0.i = or i1 %.ret.0.off0.i, %cmp10.i
(Note the first ‘or’ operand is now %.ret.0.off0.i, and *NOT* %ret.0.off0.i).
And
now there is use of .ret.0.off0.i before a definition which triggers the
“endless” loop in gather():
while(!DFT.empty()) {
V = DFT.pop_back_val(); // V is .ret.0.off0.i
if (Instruction *I = dyn_cast<Instruction>(V)) {
// If it is a || (or && depending on isEQ), process the operands.
if (I->getOpcode() == (isEQ ? Instruction::Or : Instruction::And)) {
DFT.push_back(I->getOperand(1)); // This is now .ret.0.off0.i also
DFT.push_back(I->getOperand(0));
continue; // “endless loop” for .ret.0.off0.i
}
Reviewers: reames, ahatanak
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16839
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259730 91177308-0d34-0410-b5e6-96231b3b80d8
