Neither of these cases really require a temporary APInt outside the loop. For the ConstantDataSequential case the APInt will never be larger than 64-bits so its fine to just call getElementAsAPInt. For ConstantVector we can get the APInt by reference and only make a copy where the inversion is needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316265 91177308-0d34-0410-b5e6-96231b3b80d8
The way that splitInnerLoopHeader splits blocks requires that
the induction PHI will be the first PHI in the inner loop
header. This makes sure that is actually the case when there
are both IV and reduction phis.
Differential Revision: https://reviews.llvm.org/D38682
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316261 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need to do any additional recursion, we just need to analyze the APInt stored in the node. This matches what the ValueTracking versions do for IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316256 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We shouldn't recurse any further but it doesn't mean we shouldn't be able to give the known bits for a constant. The caller would probably like that we always return the right answer for a constant RHS. This matches what InstCombine does in this case.
I don't have a test case because this showed up while trying to revive D31724.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: arsenm, llvm-commits
Differential Revision: https://reviews.llvm.org/D38967
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316255 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test.
Patch by Riyaz V Puthiyapurayil
Reviewers: craig.topper, schweitz
Reviewed By: craig.topper, schweitz
Subscribers: RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D38668
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316254 91177308-0d34-0410-b5e6-96231b3b80d8
ComplexRendererFn -> ComplexRendererFns
Corrected a couple lingering references to tied operands that were missed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316237 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:
error: relocation against symbol in discarded section: .xdata
It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.
At a high level, this is being generated:
A (.text comdat) -> B (.text) -> C (.xdata comdat)
Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.
With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).
This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).
It appears that MSVC makes the __ehhandler function comdat.
Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?
Reviewers: rnk, majnemer, compnerd, smeenai
Reviewed By: rnk, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38940
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316219 91177308-0d34-0410-b5e6-96231b3b80d8
Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316218 91177308-0d34-0410-b5e6-96231b3b80d8
We ignore the 32-bit/64-bit triple but I've tried to use i686 triples for CPUs that don't support x86_64
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316217 91177308-0d34-0410-b5e6-96231b3b80d8
(recommit #2 after checking for timeout issue).
The original patch was an improvement to IR ValueTracking on
non-negative integers. It has been checked in to trunk (D18777,
r284022). But was disabled by default due to performance regressions.
Perf impact has improved. The patch would be enabled by default.
Reviewers: reames, hfinkel
Differential Revision: https://reviews.llvm.org/D34101
Patch by: Olga Chupina <olga.chupina@intel.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316208 91177308-0d34-0410-b5e6-96231b3b80d8
