Implement a TODO from rL371452, and handle loop invariant addresses in predicated blocks. If we can prove that the load is safe to speculate into the header, then we can avoid using a masked.load in favour of a normal load.
This is mostly about vectorization robustness. In the common case, it's generally expected that LICM/LoadStorePromotion would have eliminated such loads entirely.
Differential Revision: https://reviews.llvm.org/D67372
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371745 91177308-0d34-0410-b5e6-96231b3b80d8
In MVE, as of rL371218, we are attempting to sink chains of instructions such as:
%l1 = insertelement <8 x i8> undef, i8 %l0, i32 0
%broadcast.splat26 = shufflevector <8 x i8> %l1, <8 x i8> undef, <8 x i32> zeroinitializer
In certain situations though, we can end up breaking the dominance relations of
instructions. This happens when we sink the instruction into a loop, but cannot
remove the originals. The Use is updated, which might in fact be a Use from the
second instruction to the first.
This attempts to fix that by reversing the order of instruction that are sunk,
and ensuring that we update the uses on new instructions if they have already
been sunk, not the old ones.
Differential Revision: https://reviews.llvm.org/D67366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371743 91177308-0d34-0410-b5e6-96231b3b80d8
When trying to run test-release.sh on Solaris 11.4 for 9.0.0 rc4, I failed initially
because Solaris lacks chrpath. This patch accounts for that and allowed the run to
continue.
Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D67484
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371741 91177308-0d34-0410-b5e6-96231b3b80d8
Folding for fma/fmuladd was added here:
rL202914
...and as seen in existing/unchanged tests, that works to propagate NaN
if it's already an input, but we should fold an fma() that creates NaN too.
From IEEE-754-2008 7.2 "Invalid Operation", there are 2 clauses that apply
to fma, so I added tests for those patterns:
c) fusedMultiplyAdd: fusedMultiplyAdd(0, ∞, c) or fusedMultiplyAdd(∞, 0, c)
unless c is a quiet NaN; if c is a quiet NaN then it is implementation
defined whether the invalid operation exception is signaled
d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction of
infinities, such as: addition(+∞, −∞)
Differential Revision: https://reviews.llvm.org/D67446
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371735 91177308-0d34-0410-b5e6-96231b3b80d8
IRTranslator creates G_DYN_STACKALLOC instruction during expansion of
alloca when argument that tells number of elements to allocate on stack
is a virtual register. Use default lowering for MIPS32.
Differential Revision: https://reviews.llvm.org/D67440
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371728 91177308-0d34-0410-b5e6-96231b3b80d8
G_IMPLICIT_DEF is used for both integer and floating point implicit-def.
Handle G_IMPLICIT_DEF as ambiguous opcode in MipsRegisterBankInfo.
Select G_IMPLICIT_DEF for MIPS32.
Differential Revision: https://reviews.llvm.org/D67439
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371727 91177308-0d34-0410-b5e6-96231b3b80d8
This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM.
FastISel is mostly disabled for now since it would generate incorrect code for
ILP32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371722 91177308-0d34-0410-b5e6-96231b3b80d8
Up to now, we've decided whether to sink address calculations using GEPs or
normal arithmetic based on the useAA hook, but there are other reasons GEPs
might be preferred. So this patch splits the two questions, with a default
implementation falling back to useAA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371721 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I don't have a direct motivational case for this,
but it would be good to have this for completeness/symmetry.
This pattern is basically the motivational pattern from
https://bugs.llvm.org/show_bug.cgi?id=43251
but with different predicate that requires that the offset is non-zero.
The completeness bit comes from the fact that a similar pattern (offset != zero)
will be needed for https://bugs.llvm.org/show_bug.cgi?id=43259,
so it'd seem to be good to not overlook very similar patterns..
Proofs: https://rise4fun.com/Alive/21b
Also, there is something odd with `isKnownNonZero()`, if the non-zero
knowledge was specified as an assumption, it didn't pick it up (PR43267)
Reviewers: spatel, nikic, xbolva00
Reviewed By: spatel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67411
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371718 91177308-0d34-0410-b5e6-96231b3b80d8
Current implementation of estimating divisions loses precision since it
estimates reciprocal first and does multiplication. This patch is to re-order
arithmetic operations in the last iteration in DAGCombiner to improve the
accuracy.
Reviewed By: Sanjay Patel, Jinsong Ji
Differential Revision: https://reviews.llvm.org/D66050
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371713 91177308-0d34-0410-b5e6-96231b3b80d8
This was previously used to turn fp128 operations into libcalls
on X86. This is now done through op legalization after r371672.
This restores much of this code to before r254653.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371709 91177308-0d34-0410-b5e6-96231b3b80d8
We have been using -switch-inst-prof-update-wrapper-strict
set to true by default for some time. It is time to remove
the safety stuff and make SwitchInstProfUpdateWrapper
intolerant to inconsistencies in !prof branch_weights
metadata of SwitchInst.
This patch gets rid of the Invalid state of
SwitchInstProfUpdateWrapper and the option
-switch-inst-prof-update-wrapper-strict. So there is only
two states: changed and unchanged.
Reviewers: davidx, nikic, eraman, reames, chandlerc
Reviewed By: davidx
Differential Revision: https://reviews.llvm.org/D67435
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371707 91177308-0d34-0410-b5e6-96231b3b80d8
Fixing a couple of asan-identified bugs
* use of an invalid "Use" iterator after the element was removed
* use of StringRef to Function name after the Function was erased
This reapplies r371567, which was reverted in r371580.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371700 91177308-0d34-0410-b5e6-96231b3b80d8
This modifies the tool somewhat to only create files when about to run
the "interestingness" test, and delete them immediately after - this
means some more files will be created sometimes (when "double checking"
work - which should probably be fixed/avoided anyway).
This now creates temporary files, rather than only unique ones, and also
uses ToolOutputFile (without ever calling "keep") to ensure the files
are deleted as soon as the interestingness test is run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371696 91177308-0d34-0410-b5e6-96231b3b80d8
AVX512 instructions can cause a frequency drop on these CPUs. This
can negate the performance gains from using wider vectors. Enabling
prefer-vector-width=256 will prevent generation of zmm registers
unless explicit 512 bit operations are used in the original source
code.
I believe gcc and icc both do something similar to this by default.
Differential Revision: https://reviews.llvm.org/D67259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371694 91177308-0d34-0410-b5e6-96231b3b80d8
First we were asserting that the ValNo of a VA was the wrong value. It doesn't actually
make a difference for us in CallLowering but fix that anyway to silence the assert.
The bigger issue was that after fixing the assert we were generating invalid MIR
because the merging/unmerging of values split across multiple registers wasn't
also implemented for memory locs. This happens when we run out of registers and
have to pass the split types like i128 -> i64 x 2 on the stack. This is do-able, but
for now just fall back.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371693 91177308-0d34-0410-b5e6-96231b3b80d8
Before, we only checked the callee for swifterror. However, we should also be
checking the caller to see if it has a swifterror parameter.
Since we don't currently handle outgoing arguments, this didn't show up in the
swifterror.ll testcase.
Also, remove the swifterror checks from call-translator-tail-call.ll, since
they are covered by the existing swifterror testing. Better to have it all in
one place.
Differential Revision: https://reviews.llvm.org/D67465
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371692 91177308-0d34-0410-b5e6-96231b3b80d8
Doing the CRLF translation while writing the file defeats our
optimization to not update the file if it hasn't changed.
Fixes PR43271.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371683 91177308-0d34-0410-b5e6-96231b3b80d8
I found three issues:
1. the loop over E[ABCD]X copies run over BB start
2. the direct address of cmpxchg8b could be a frame index
3. the displacement of cmpxchg8b could be a global instead of an
immediate
These were all introduced together in r287875, and should be fixed with
this change.
Issue reported by Zachary Turner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371678 91177308-0d34-0410-b5e6-96231b3b80d8
I think this case would crash before I added back the -x86-experimental-vector-widening command line option. Adding this test case to prevent breaking it again when we remove the option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371673 91177308-0d34-0410-b5e6-96231b3b80d8
fp128 is considered a legal type for a register, but has almost no legal operations so everything needs to be converted to a libcall. Previously this was implemented by tricking type legalization into softening the operations with various checks for "is legal in hardware register" to change the behavior to still use f128 as the resulting type instead of converting to i128.
This patch abandons this approach and instead moves the libcall conversions to LegalizeDAG. This is the approach taken by AArch64 where they also have a legal fp128 type, but no legal operations. I think this is more in spirit with how SelectionDAG's phases are supposed to work.
I had to make some hacks for STRICT_FP_ROUND because some of the strict FP handling checks if ISD::FP_ROUND is Legal for a given result type, but I had to make ISD::FP_ROUND Custom to allow making a libcall when the input is f128. For all other types the Custom handler just returns the original node. These hacks are incomplete and don't work for a strict truncate from f128, but I don't think it worked before either since LegalizeFloatTypes doesn't know about strict ops yet. I've also raised PR43209 against AArch64 which currently crashes on a strict ftrunc from f64->f32 because of FP_ROUND being marked Custom for the same reason there.
Differential Revision: https://reviews.llvm.org/D67128
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371672 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
After hoisting and merging m0 initializations schedule them as early as
possible in the MBB. This helps the scheduler avoid hazards in some
cases.
Reviewers: rampitec, arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67450
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371671 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: If an error is ever returned from any of the functions called here, the error must be joined with the Result Error before being returned otherwise the Result Error will assert on destruction.
Reviewers: lhames
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67407
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371662 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the ability to create a gsym::LineTable object, populate it, encode and decode it and test all functionality.
The full format of the LineTable encoding is specified in the header file LineTable.h.
Differential Revision: https://reviews.llvm.org/D66602
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371657 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::sys::ExecuteAndWait can report errors, so let's make use of that.
Second, while iterating uses of functions to remove, a call can appear
multiple times. Use a SetVector so we don't attempt to erase such a call
twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371653 91177308-0d34-0410-b5e6-96231b3b80d8
