Age | Commit message (Collapse) | Author |
|
This patch adds the necessary infrastructure to convert instructions that
take two register operands to those that take a register and immediate if
the necessary operand is produced by a load-immediate. Furthermore, it uses
this infrastructure to perform such conversions twice - first at MachineSSA
and then pre-emit.
There are a number of reasons we may end up with opportunities for this
transformation, including but not limited to:
- X-Form instructions chosen since the exact offset isn't available at ISEL time
- Atomic instructions with constant operands (we will add patterns for this
in the future)
- Tail duplication may duplicate code where one block contains this redundancy
- When emitting compare-free code in PPCDAGToDAGISel, we don't handle constant
comparands specially
Furthermore, this patch moves the initialization of PPCMIPeepholePass so that
it can be used for MIR tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320791 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A couple places didn't use the same SDValue variables to connect everything all the way through.
I don't have a test case for a bug in insert into the lower bits of a non-zero, non-undef vector. Not sure the best way to create that. We don't create the case when lowering concat_vectors which is the main way to get insert_subvectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320790 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We cannot move the insertion point to header if SCEV contains div/rem
operations due to they may go over check for zero denominator.
Reviewers: sanjoy, mkazantsev, sebpop
Reviewed By: sebpop
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41229
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320789 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The regression on ppc64 was not due to this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The compare elimination peephole introduced in https://reviews.llvm.org/rL312514
causes a miscompile in AMDGPUInstrInfo.cpp which in turn causes some AMDGPU
test case failures in stage2 bootstrap testing. This miscompile didn't cause any
test case failures until https://reviews.llvm.org/rL320614, so it appeared as if
that patch caused these failures.
Disabling this transformation for now to bring the build bots back to green and
the author of the patch will investigate the miscompile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
macOS paths usually start with /Users, which clang-cl interprets as a
macro undefine, leading to pretty much everything failing to compile.
CMake should be taught to put a -- in its compilation rules for clang-cl
(and I've been meaning to submit that upstream for a while). In the
meantime, however, and to support older CMake versions, we can just
create a custom make rules override to fix the compilation rules.
Differential Revision: https://reviews.llvm.org/D41219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320784 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operands call NewSDValueDbgMsg.
This makes it work better with some build_vector and concat_vectors creations.
Adjust the NewSDValueDbgMsg in getConstant to avoid duplicating the print when it calls getSplatBuildVector since getSplatBuildVector didn't trigger a print before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that require 512-bit registers OR VLX into separate sections. NFCI
We have several instructions that were introduced in AVX512F that are only available in 512-bit form on KNL. We still make use of them for 128/256 by artificially widening and extracting during isel.
This commit separates these operations from the true 512-bit operations. This way we can qualify the normal 512-bit operations with needing 512-bit register support. And these special operations will get qualified with needing 512-bit registers OR VLX.
The 512-bit register qualification will be introduced in a future patch this just gets everything grouped to minimize deltas on that patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously they were sort of interleaved in with XMM/YMM/ZMM action related code.
Trying to separate things so its easier to split 512-bit vectors later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
be custom lowering inserting v1i1 into v8i1 under this.
I don't have a test case at the moment. Just noticed while auditing things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the X86ISelLowering constructor. NFCI
Move it into the separate hasVLX block later in the constructor.
I'm trying to separate 128/256 and 512-bit related code so we can eventually qualify the hasAVX512 block with support for 512-bit vectors required by the prefer-vector-width feature support being talked about in D41096.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add support for properly handling PIC code with no-PLT. This equates to
`-fpic -fno-plt -O0` with the clang frontend. External functions are
marked with nonlazybind, which must then be indirected through the GOT.
This allows code to be built without optimizations in PIC mode without
going through the PLT. Addresses PR35653!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a special code that indicates that it's a function id.
While I'm still not certain how to interpret these, we definitely
should *not* be using these values as indices into an array directly.
For now, when we encounter one of these, just print the numeric value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320775 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
- lowers @llvm.global_dtors by adding @llvm.global_ctors
functions which register the destructors with `__cxa_atexit`.
- impements @llvm.global_ctors with wasm start functions and linker metadata
See [here](https://github.com/WebAssembly/tool-conventions/issues/25) for more background.
Subscribers: jfb, dschuff, mgorny, jgravelle-google, aheejin, sunfish
Differential Revision: https://reviews.llvm.org/D41211
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Now that r320495, "[debuginfo-tests] Support moving
debuginfo-tests to llvm/projects," has landed, which includes a local
copy of test_debuginfo.pl, remove the obsolete copy.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D41260
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320768 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This change swaps FunctionSamples to a std::map. This saves us around
17% of the memory required to parse sample profiles. To put hard numbers
on this, clang now eats around 1.3GB of RAM instead of 1.6GB while
parsing a 50MB profile.
The CPU time taken by a large profile merge (3.1GB of data across 226
files) is also reduced by ~11% by this patch (1:09.08 vs 1:01.11).
This was split out at the request of reviewers in D41152.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add Exynos M2/M3 to extension check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fix formatting by adding a missing blank line to test new network setup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While investigating LLVM PR22316 (http://llvm.org/bugs/show_bug.cgi?id=22316)
I started wondering if it were not always preferable to emit the
initial DBG_VALUEs for stack arguments as FI locations instead of
describing the first register they get copied into. The advantage of
doing this is that the arguments will be available as soon as the
stack is setup. As illustrated by the testcase in the PR, the first
copy of the FI into a register may be sunk by MachineSink.cpp into a
later basic block. By describing the argument on the stack, we nicely
circumvent this problem.
<rdar://problem/19583723>
Differential Revision: https://reviews.llvm.org/D41135
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SDNode's we're still holding SDValues for. NFCI
We can just get the chains from those SDValues to create the TokenFactor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Most of the -Wsign-compare warnings are due to the fact that
enums are signed by default in the MS ABI, while the
tautological comparison warnings trigger on x86 builds where
sizeof(size_t) is 4 bytes, so N > numeric_limits<unsigned>::max()
is always false.
Differential Revision: https://reviews.llvm.org/D41256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should solve:
https://bugs.llvm.org/show_bug.cgi?id=34603
...by preventing SimplifyCFG from altering redundant instructions before early-cse has a chance to run.
It changes the default (canonical-forming) behavior of SimplifyCFG, so we're only doing the
sinking transform later in the optimization pipeline.
Differential Revision: https://reviews.llvm.org/D38566
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rather than adding more bits to express every
MMO flag you could want, just directly use the
MMO flags. Also fixes using a bunch of bool arguments to
getMemIntrinsicNode.
On AMDGPU, buffer and image intrinsics should always
have MODereferencable set, but currently there is no
way to do that directly during the initial intrinsic
lowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change lays the groundwork lowering of @llvm.global_ctors
and @llvm.global_dtors for the wasm object format. Some parts
of this patch are subset of: https://reviews.llvm.org/D40759
See https://github.com/WebAssembly/tool-conventions/issues/25
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish
Differential Revision: https://reviews.llvm.org/D41208
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320742 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit ac5edc198eb612f82293850c3488042708b1c5fa.
Apparently this doesn't cover all the bases, so some compilers
and standard libraries still think this is not trivially copyable
even though it is. Reverting this back to an MSVC-only check for
now so that at least we have some coverage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should be a better check than using is_trivially_copyable
behind an #ifdef _MSC_VER.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320737 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In SLPVectorizer, the vector build instructions (insertvalue for aggregate type) is passed to BoUpSLP.buildTree, it is treated as UserIgnoreList, so later in cost estimation, the cost of these instructions are not counted.
For aggregate value, later usage are more likely to be done in scalar registers, either used as individual scalars or used as a whole for function call or return value. Ignore scalar extraction instructions may cause too aggressive vectorization for aggregate values, and slow down performance. So for vectorization of aggregate value, the scalar extraction instructions are required in cost estimation.
Differential Revision: https://reviews.llvm.org/D41139
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Apparently this isn't present on older versions of libstdc++, so
it causes some builds to fail.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Hexagon HVX has type v128i8, comparing two vectors of that type will
produce v128i1 types in SelectionDAG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320727 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a Swift feature. The output stream for the index page and the source
HTML page is utf-8 now.
The next patch will add the HTML magic to properly render these characters in
the browser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320725 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Newer versions of CMake (I'm on 3.10, but I believe 3.9 behaves the same
way) attempt to query the system for information about the VS 2017
install. Unfortunately, this query fails on non-Windows systems:
cmake_host_system_information does not recognize <key> VS_15_DIR
CMake isn't going to find these system libraries on non-Windows anyway
(and we were previously silencing the resultant warnings in our
cross-compilation toolchain), so it makes sense to just omit the
attempted installation entirely on non-Windows.
Differential Revision: https://reviews.llvm.org/D41220
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bit from a vXi1.
This doesn't match the semantics of the extract_vector_elt operation. Nothing downstream knows the bits were zeroed so they still get masked or sign extended after the extrat anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
HVX does not support operations on 64-bit integers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320722 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While I'm pushing cleanup changes, this also fixes a few warnings
related to extraneous semicolons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320720 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds the /DEBUG:GHASH option to LLD which will look for
the existence of .debug$H sections in linker inputs and use them
to accelerate type merging. The clang-cl side has already been
added, so this completes the work necessary to begin experimenting
with this feature.
Differential Revision: https://reviews.llvm.org/D40980
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320719 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes expensive-check ARM buildbot failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320718 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
set.<NFC>
NFC.
Adding MC regressions tests to cover the AVX and AVX2 ISA sets.
This patch is part of a larger task to cover MC encoding of all X86 ISA Sets.
See revision: https://reviews.llvm.org/D39952
Reviewers: zvi, RKSimon, aymanmus, m_zuckerman
Differential Revison: https://reviews.llvm.org/D40287
Change-Id: I304687a2b7abb473f79de99c31fc55c97b2662da
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320716 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This commit might have caused regression on ppc64. Revert it to verify that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320712 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The generated diagnostic by the AsmMatcher isn't always applicable to the AsmOperand.
This is because the code will only update the diagnostic if it is more
specific than the previous diagnostic. However, when having validated
operands and 'moved on' to a next operand (for some instruction/alias for
which all previous operands are valid), if the diagnostic is InvalidOperand,
than that should be set as the diagnostic, not the more specific message
about a previous operand for some other instruction/alias candidate.
(Re-committed with an extra whitespace in SVEInstrFormats.td to trigger rebuild
of AArch64GenAsmMatcher.inc, since the llvm-clang-x86_64-expensive-checks-win
builder does not seem to rebuild AArch64GenAsmMatcher.inc with the
newly built TableGen due to a missing dependency somewhere (see:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119555.html))
Reviewers: craig.topper, olista01, rengolin, stoklund
Reviewed By: olista01
Subscribers: javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D40011
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential revision: https://reviews.llvm.org/D41238
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MIPSR6 introduced several new jump instructions and deprecated
the use of the 'j' instruction. For microMIPS32R6, 'j' was removed
entirely and it only has non delay slot jumps.
This patch adds support for MIPSR6 by using some R6 instructions--
'bc' instead of 'j', 'jic $reg, 0' instead of 'jalr $zero, $reg'--
and modifies the sequences not to use delay slots for R6.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: dschuff, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D40786
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The function is meant to recurse until it comes upon the
phi it's looking for. However, with the current condition,
it will recurse until it finds anything _but_ the phi.
The function will even fail for simple cases like:
%i = phi i32 [ %inc, %loop ], ...
...
%inc = add i32 %i, 1
because the base condition will not happen when the phi
is recursed to, and the recursion will end with a 'false'
result since the previous instruction is a phi.
Reviewers: sanjoy, atrick
Reviewed By: sanjoy
Subscribers: Ka-Ka, bjope, llvm-commits
Committing on behalf of: Bevin Hansson (bevinh)
Differential Revision: https://reviews.llvm.org/D40946
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320700 91177308-0d34-0410-b5e6-96231b3b80d8
|