| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
DeleteDeadBlock was called indiscriminately, leading to cleanuprets with
undef cleanuppad references.
Instead, try to drain the BB of most of it's instructions if it is
unreachable. We can then remove the BB if it solely consists of a
terminator (and maybe some phis).
llvm-svn: 261731
|
| |
|
|
|
|
|
| |
We didn't have a mapping from LLVM's x87 floating point registers to
CodeView's encoding.
llvm-svn: 261730
|
| |
|
|
|
|
| |
PerformShuffleCombine should be usable by unary and binary target shuffles, but was attempting to get the first two operands whatever the instruction type. Since these are only used for VECTOR_SHUFFLE instructions for one particular combine I've moved them inside the relevant if statement.
llvm-svn: 261727
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17538
llvm-svn: 261725
|
| |
|
|
|
|
|
|
| |
support 256bit inputs like AVX patterns ( that are disable in case HasVLX , see SS41I_pmovx_avx2_patterns).
Differential Revision: http://reviews.llvm.org/D17504
llvm-svn: 261724
|
| |
|
|
|
|
|
|
|
|
|
| |
This function is used in exactly one place, and only in asserts
builds. Move it a few lines up before the use and only define it when
asserts are enabled. Fixes the release build under -Werror.
Also remove the forward declaration and commentary that was basically
identical to the code itself.
llvm-svn: 261722
|
| |
|
|
|
|
|
| |
Don't do an expensive computeKnownBits call when we
can do the cheap check for legal offsets first.
llvm-svn: 261720
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: The 'and' case in foldCastedBitwiseLogic() is inheriting one extra
check from the nearly identical 'or' case:
if ((!isa<ICmpInst>(Cast0Src) || !isa<ICmpInst>(Cast1Src))
But I'm not sure how to expose that difference in a regression test.
Without that check, the 'or' path will infinite loop on:
test/Transforms/InstCombine/zext-or-icmp.ll
because the zext-or-icmp fold is attempting a reverse transform.
The refactoring should extend to the 'xor' case next to solve part of
PR26702.
llvm-svn: 261707
|
| |
|
|
|
|
| |
This reverts r261685 due to wasm test breakage.
llvm-svn: 261702
|
| |
|
|
|
|
|
| |
Looks like the global rename last year was a bit over-zealous. These things
really are referred to with ARM64 elsewhere (ld64, libunwind, ...).
llvm-svn: 261698
|
| |
|
|
| |
llvm-svn: 261685
|
| |
|
|
|
|
|
|
| |
We were emitting only one half of a the paired relocations needed for these
instructions because we decided that an offset needed a scattered relocation.
In fact, movw/movt relocations can be paired without being scattered.
llvm-svn: 261679
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, jmolloy
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17546
llvm-svn: 261675
|
| |
|
|
|
|
|
|
| |
debug info."
This and the corresponding Clang change caused PR26715.
llvm-svn: 261671
|
| |
|
|
| |
llvm-svn: 261666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, the ARM Constant Island may not converge (or not converge quickly).
This patch let it move to the closest water after the user if it doesn't converge after 15 iterations.
This address https://llvm.org/bugs/show_bug.cgi?id=25339
Reviewers: t.p.northover, srhines, kristof.beyls, aadg, rengolin
Subscribers: weimingz, aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D16890
llvm-svn: 261665
|
| |
|
|
| |
llvm-svn: 261664
|
| |
|
|
|
|
|
|
|
|
|
| |
Implements a mostly-conventional redzone for the userspace
stack. Because we have unsigned load/store offsets we continue to use a
local SP subtracted from the incoming SP but do not write it back to
memory.
Differential Revision: http://reviews.llvm.org/D17525
llvm-svn: 261662
|
| |
|
|
|
|
| |
Less indenting, named local variables, more descriptive names.
llvm-svn: 261659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locally unwind
It is problematic if the inlinee has a cleanupret which unwinds to
caller and we inline it into a call site which doesn't unwind.
If the funclet unwinds anywhere other than to the caller,
then we will give the funclet two unwind destinations.
This will result in a verifier failure.
Seeing as how the caller wasn't an invoke (which would locally unwind)
and that the funclet cannot unwind to caller, we must conclude that an
'unwind to caller' cleanupret is dynamically unreachable.
This fixes PR26698.
Differential Revision: http://reviews.llvm.org/D17536
llvm-svn: 261656
|
| |
|
|
| |
llvm-svn: 261652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix a bug in epilog generation where the incoming stack arguments were
not being popped for fastcc functions when -tailcallopt was passed.
Reviewers: t.p.northover, mcrosier, jmolloy, rengolin
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16894
llvm-svn: 261650
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a straight cut and paste of the existing code and is intended to
be the first step in solving part of PR26702:
https://llvm.org/bugs/show_bug.cgi?id=26702
We should be able to reuse most of this and delete the nearly identical
existing code in visitOr(). Then, we can enhance visitXor() to use the
same code too.
llvm-svn: 261649
|
| |
|
|
| |
llvm-svn: 261640
|
| |
|
|
| |
llvm-svn: 261637
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15976
llvm-svn: 261633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pattern that triggers it. This essentially requires an immutable
function analysis, as that will survive anything we do to invalidate it.
When we have such patterns, the function analysis manager will not get
cleared between runs of the proxy.
If we actually need an assert about how things are queried, we can add
more elaborate machinery for computing it, but so far I'm not aware of
significant value provided.
Thanks to Justin Lebar for noticing this when he made a (seemingly
innocuous) change to FunctionAttrs that is enough to trigger it in one
test there. Now it is covered by a direct test of the pass manager code.
llvm-svn: 261627
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we want classify OoO or not, using getSchedModel().isOutOfOrder()
could be more proper way than using Subtarget->isLikeA9().
Reviewers: jmolloy, rengolin
Differential Revision: http://reviews.llvm.org/D17433
llvm-svn: 261623
|
| |
|
|
|
|
|
|
|
|
|
| |
src1 of s_bfe_u64 is 32-bit (same as s_bfe_i64).
src0 and src1 of s_bfm_b64 are 32-bit.
Update tests.
Review: http://reviews.llvm.org/D17480
Reviewers: arsenm
llvm-svn: 261621
|
| |
|
|
|
|
|
|
| |
version of this instructions return result in kmask register, so AVX patterns should not be disabled.
Differential Revision: http://reviews.llvm.org/D17517
llvm-svn: 261619
|
| |
|
|
|
|
|
| |
We had the right logic for the nested cleanuppad case but omitted it for
catchswitches.
llvm-svn: 261615
|
| |
|
|
| |
llvm-svn: 261614
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: If a function is hot, put it in text.hot section.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17532
llvm-svn: 261607
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change TargetInstrInfo API to take `MachineInstr&` instead of
`MachineInstr*` in the functions related to predicated instructions
(I'll try to come back later and get some of the rest). All of these
functions require non-null parameters already, so references are more
clear. As a bonus, this happens to factor away a host of implicit
iterator => pointer conversions.
No functionality change intended.
llvm-svn: 261605
|
| |
|
|
|
|
|
|
| |
This reverts commit r261582, since this bot has been broken for four
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/19399/
llvm-svn: 261604
|
| |
|
|
| |
llvm-svn: 261600
|
| |
|
|
| |
llvm-svn: 261597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we completely unroll a loop, it's pretty easy to update DT in-place and
thus avoid rebuilding it. DT recalculation is one of the most time-consuming
tasks in loop-unroll, so avoiding it at least in case of full unroll should be
beneficial.
On some extreme (but still real-world) tests this patch improves compile time by
~2x.
Reviewers: escha, jmolloy, hfinkel, sanjoy, chandlerc
Subscribers: joker.eph, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D17473
llvm-svn: 261595
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are really handles that ensure the analyses get cleared at
appropriate places, and as such copying doesn't really make sense.
Instead, they should look more like unique ownership objects. Make that
the case.
Relatedly, if you create a temporary of one and move out of it
its destructor shouldn't actually clear anything. I don't think there is
any code that can trigger this currently, but it seems like a more
robust implementation.
If folks want, I can add a unittest that forces this to be exercised,
but that seems somewhat pointless -- whether a temporary is ever created
in the innards of AnalysisManager is not really something we should be
adding a reliance on, but I didn't want to leave a timebomb in the code
here.
If anyone has a cleaner way to represent this, I'm all ears, but
I wanted to assure myself that this wasn't in fact responsible for
another bug I'm chasing down (it wasn't) and figured I'd commit that.
llvm-svn: 261594
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16857
llvm-svn: 261589
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixing buildbot failure introduced by http://reviews.llvm.org/D17460
Reviewers: davidxl, hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17524
llvm-svn: 261588
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change makes the sample profile's behavior consistent with instr profile.
Reviewers: davidxl, eraman, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17522
llvm-svn: 261587
|
| |
|
|
|
|
|
| |
We supported creating mergeable constant pool entries for smaller
constants but not for 32-byte AVX constants.
llvm-svn: 261584
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: If a function is hot, put it in text.hot section.
Reviewers: davidxl
Subscribers: eraman, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17460
llvm-svn: 261582
|
| |
|
|
|
|
|
|
|
|
|
| |
This was causing assertions later from using the wrong pointer
size with LDS operations. getOptimalMemOpType should also have
address space arguments later.
This avoids assertions in existing tests exposed by
a future commit.
llvm-svn: 261580
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously the stack pointer was only written back to memory in the
prolog. But this is wrong for dynamic allocas, for which
target-independent codegen handles SP updates after the prolog (and
possibly even in another BB). Instead update the SP global in
ADJCALLSTACKDOWN which is generated after the SP update sequence.
This will have further refinements when we add red zone support.
llvm-svn: 261579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since this is an IR pass it's nice to be able to write tests without
llc. This is the counterpart of the llc test under
CodeGen/PowerPC/loop-data-prefetch.ll.
Reviewers: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17464
llvm-svn: 261578
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a little embarrassing.
When I reverted r261504 (getIterator() => getInstrIterator()) in
r261567, I did a `git grep` to see if there were new calls to
`getInstrIterator()` that I needed to migrate. There were 10-20 hits,
and I blindly did a `sed ...` before calling `ninja check`.
However, these were `MachineInstrBundleIterator::getInstrIterator()`,
which predated r261567. Perhaps coincidentally, these had an identical
name and return type.
This commit undoes my careless sed and restores
`MachineBasicBlock::iterator::getInstrIterator()`.
llvm-svn: 261577
|
| |
|
|
|
|
|
|
| |
The issue was that we only required LCSSA rebuilding if the immediate
parent-loop had values used outside of it. The fix is to enaable the
same logic for all outer loops, not only immediate parent.
llvm-svn: 261575
|
| |
|
|
| |
llvm-svn: 261573
|