- Use auto
- Name variables in LLVM style
- Use llvm::find instead of std::find
- Blank lines between declarations
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264129 91177308-0d34-0410-b5e6-96231b3b80d8
Now that StatepointLoweringInfo represents base pointers, derived
pointers and gc relocates as SmallVectors and not ArrayRefs, we no
longer need to allocate "backing storage" on stack in LowerStatepoint.
So elide the backing storage, and inline the trivial body of
getIncomingStatepointGCValues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264128 91177308-0d34-0410-b5e6-96231b3b80d8
We can statically decide whether or not a register pressure set is for
SGPRs or VGPRs, so we don't need to re-compute this information in
SIRegisterInfo::getRegPressureSetLimit().
Differential Revision: http://reviews.llvm.org/D14805
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264126 91177308-0d34-0410-b5e6-96231b3b80d8
In retrospect, it seems "obvious" that the sense of the return code is
the same as if it crashed on "interesting" inputs. But that didn't stop
me from spending more time than I care to admit verifying this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264119 91177308-0d34-0410-b5e6-96231b3b80d8
MCContext shouldn't be accessing the filesystem - that's a gross
layering violation and makes it awkward to use as a library or in a
daemon where it may not even be allowed filesystem access.
The CWD lookup here is normally redundant anyway, since the calling
context either also looks up the CWD or sets this to something more
specific. Here, we fix up the one caller that doesn't already set up a
debug compilation dir and make it clear that the responsibility for
such set up is in the users of MCContext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264109 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I've completed my audit of all the code that looks at noduplicate and
added handling of convergent where appropriate, so we no longer need
noduplicate on these intrinsics.
Reviewers: jholewinski
Subscribers: llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D18168
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264107 91177308-0d34-0410-b5e6-96231b3b80d8
A really unfortunate design of llvm-link and related libraries is that
they operate one module at a time.
This means they can copy a GV to the destination module that should not
be there in the final result because a later bitcode file takes
precedence.
We already handled cases like a strong GV replacing a weak for example.
One case that is not currently handled is a comdat replacing another.
This doesn't happen in ELF, but with COFF largest selection kind it is
possible.
In "llvm-link a.ll b.ll" if the selected comdat was from a.ll,
everything will work and we will not copy the comdat from b.ll.
But if we run "llvm-link b.ll a.ll", we fail to delete the already
copied comdat from b.ll. This patch fixes that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264103 91177308-0d34-0410-b5e6-96231b3b80d8
Found during fuzz testing - 32-bit x86 targets were legalizing a <2 x i1> compare result to <2 x i32> when <2 x i64> was expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264085 91177308-0d34-0410-b5e6-96231b3b80d8
We were just completely ignoring the types when determining whether we could
safely emit a libcall as a tail call. This is clearly wrong.
Theoretically, we could dig deeper looking for incidental matches (much like
the generic code in Analysis.cpp does), but it's probably not worth it for the
few libcalls that exist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264084 91177308-0d34-0410-b5e6-96231b3b80d8
When you have multiple LCSSA (single-operand) PHIs that are converted
into two-operand PHIs due to versioning, only assert that the PHI
currently being converted has a single operand. I.e. we don't want to
check PHIs that were converted earlier in the loop.
Fixes PR27023.
Thanks to Karl-Johan Karlsson for the minimized testcase!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264081 91177308-0d34-0410-b5e6-96231b3b80d8
Improve vector extension of vectors on hardware without dedicated VSEXT/VZEXT instructions.
We already convert these to SIGN_EXTEND_VECTOR_INREG/ZERO_EXTEND_VECTOR_INREG but can further improve this by using the legalizer instead of prematurely splitting into legal vectors in the combine as this only properly helps for lowering to VSEXT/VZEXT.
Removes a lot of unnecessary any_extend + mask pattern - (Fix for PR25718).
Reapplied with a fix for PR26953 (missing vector widening legalization).
Differential Revision: http://reviews.llvm.org/D17932
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264062 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Also renamed li_simm7 to li16_imm since it's not a simm7 and has an unusual
encoding (it's a uimm7 except that 0x7f represents -1).
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18145
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264056 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We can't check the error message for this one because there's another lw/sw
available that covers a larger range. We therefore check the transition
between the two sizes.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D18144
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264054 91177308-0d34-0410-b5e6-96231b3b80d8
It's a bug fix.
For rerolled loops SE trip count remains unchanged. It leads to incorrect work of the next passes.
My patch just resets SE info for rerolled loop forcing SE to re-evaluate it next time it requested.
I also added a verifier call in the exisitng test to be sure no invalid SE data remain. Without my fix this test would fail with -verify-scev.
Differential Revision: http://reviews.llvm.org/D18316
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264051 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
After this change, deopt operand bundles can be lowered directly by
SelectionDAG into STATEPOINT instructions (which are then lowered to a
call or sequence of nop, with an associated __llvm_stackmaps entry0.
This obviates the need to round-trip deoptimization state through
gc.statepoint via RewriteStatepointsForGC.
Reviewers: reames, atrick, majnemer, JosephTremoulet, pgavlin
Subscribers: sanjoy, mcrosier, majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D18257
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264015 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Without tree pruning clang has 2,667,552 points.
Wiht only dominators pruning: 1,515,586.
With both dominators & predominators pruning: 1,340,534.
Resubmit of r262103.
Differential Revision: http://reviews.llvm.org/D18341
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264003 91177308-0d34-0410-b5e6-96231b3b80d8
If we have a BB with only MemoryDefs, live-in calculations will ignore
it. This means we get results like this:
define void @foo(i8* %p) {
; 1 = MemoryDef(liveOnEntry)
store i8 0, i8* %p
br i1 undef, label %if.then, label %if.end
if.then:
; 2 = MemoryDef(1)
store i8 1, i8* %p
br label %if.end
if.end:
; 3 = MemoryDef(1)
store i8 2, i8* %p
ret void
}
...When there should be a MemoryPhi in the `if.end` BB.
This patch fixes that behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263991 91177308-0d34-0410-b5e6-96231b3b80d8
I added -march=hexagon to force using Hexagon target when testing
locally, and I forgot to take it out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263990 91177308-0d34-0410-b5e6-96231b3b80d8
