forked from llvm-mirror/llvm
-
Notifications
You must be signed in to change notification settings - Fork 17
merge latest from llvm mirror - Release 70 #61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
------------------------------------------------------------------------
r340927 | vstefanovic | 2018-08-29 07:07:14 -0700 (Wed, 29 Aug 2018) | 14 lines
[mips] Prevent shrink-wrap for BuildPairF64, ExtractElementF64 when they use $sp
For a certain combination of options, BuildPairF64_{64}, ExtractElementF64{_64}
may be expanded into instructions using stack.
Add implicit operand $sp for such cases so that ShrinkWrapping doesn't move
prologue setup below them.
Fixes MultiSource/Benchmarks/MallocBench/cfrac for
'--target=mips-img-linux-gnu -mcpu=mips32r6 -mfpxx -mnan=2008'
and
'--target=mips-img-linux-gnu -mcpu=mips32r6 -mfp64 -mnan=2008 -mno-odd-spreg'.
Differential Revision: https://reviews.llvm.org/D50986
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346734 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r340931 | atanasyan | 2018-08-29 07:53:55 -0700 (Wed, 29 Aug 2018) | 6 lines [mips] Involves microMIPS's jump in the analyzable branch set Involves microMIPS's jump in the analyzable branch set to reduce some code patterns. Differential revision: https://reviews.llvm.org/D50613 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346735 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r340932 | atanasyan | 2018-08-29 07:54:01 -0700 (Wed, 29 Aug 2018) | 11 lines [mips] Fix microMIPS unconditional branch offset handling MipsSEInstrInfo class defines for internal purpose unconditional branches as Mips::B nad Mips:J even in case of microMIPS code generation. Under some conditions that leads to the bug - for rather long branch which fits to Mips jump instruction offset size, but does not fit to microMIPS jump offset size, we generate 'short' branch and later show an error 'out of range PC16 fixup' after check in the isBranchOffsetInRange routine. Differential revision: https://reviews.llvm.org/D50615 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346736 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r341221 | atanasyan | 2018-08-31 08:57:17 -0700 (Fri, 31 Aug 2018) | 12 lines [mips] Fix `mtc1` and `mfc1` definitions for microMIPS R6 The `mtc1` and `mfc1` definitions in the MipsInstrFPU.td have MMRel, but do not have StdMMR6Rel tags. When these instructions are emitted for microMIPS R6 targets, `Mips::MipsR62MicroMipsR6` nor `Mips::Std2MicroMipsR6` cannot find correct op-codes and as a result the backend uses mips32 variant of the instructions encoding. The patch fixes this problem by adding the StdMMR6Rel tag and check instructions encoding in the test case. Differential revision: https://reviews.llvm.org/D51482 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346737 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r341919 | atanasyan | 2018-09-11 02:57:25 -0700 (Tue, 11 Sep 2018) | 18 lines [mips] Add a pattern for 64-bit GPR variant of the `rdhwr` instruction MIPS ISAs start to support third operand for the `rdhwr` instruction starting from Revision 6. But LLVM generates assembler code with three-operands version of this instruction on any MIPS64 ISA. The third operand is always zero, so in case of direct code generation we get correct code. This patch fixes the bug by adding an instruction alias. The same alias already exists for 32-bit ISA. Ideally, we also need to reject three-operands version of the `rdhwr` instruction in an assembler code if ISA revision is less than 6. That is a task for a separate patch. This fixes PR38861 (https://bugs.llvm.org/show_bug.cgi?id=38861) Differential revision: https://reviews.llvm.org/D51773 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346739 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r342884 | petarj | 2018-09-24 07:14:19 -0700 (Mon, 24 Sep 2018) | 12 lines [Mips][FastISel] Fix selectBranch on icmp i1 The r337288 tried to fix result of icmp i1 when its input is not sanitized by falling back to DagISel. While it now produces the correct result for bit 0, the other bits can still hold arbitrary value which is not supported by MipsFastISel branch lowering. This patch fixes the issue by falling back to DagISel in this case. Patch by Dragan Mladjenovic. Differential Revision: https://reviews.llvm.org/D52045 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346741 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r342946 | smaksimovic | 2018-09-24 23:27:49 -0700 (Mon, 24 Sep 2018) | 6 lines [mips] Correct MUL pattern for mips64 Guard existing pattern with a predicate, introduce a new one for revision 6. Differential Revision: https://reviews.llvm.org/D51684 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@346742 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r344516 | abeserminji | 2018-10-15 07:39:12 -0700 (Mon, 15 Oct 2018) | 12 lines [mips][micromips] Fix overlaping FDEs error When compiling static executable for micromips, CFI symbols are incorrectly labeled as MICROMIPS, which cause ".eh_frame_hdr refers to overlapping FDEs." error. This patch does not label CFI symbols as MICROMIPS, and FDEs do not overlap anymore. This patch also exposes another bug, which is fixed here: https://reviews.llvm.org/D52985 Differential Revision: https://reviews.llvm.org/D52987 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347023 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r344591 | abeserminji | 2018-10-16 01:27:28 -0700 (Tue, 16 Oct 2018) | 11 lines [mips][micromips] Fix how values in .gcc_except_table are calculated When a landing pad is calculated in a program that is compiled for micromips, it will point to an even address. Such an error will cause a segmentation fault, as the instructions in micromips are aligned on odd addresses. This patch sets the last bit of the offset where a landing pad is, to 1, which will effectively be an odd address and point to the instruction exactly. Differential Revision: https://reviews.llvm.org/D52985 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347028 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r345353 | sima | 2018-10-25 18:28:36 -0700 (Thu, 25 Oct 2018) | 21 lines Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929) Summary: This patch makes the dominatortree recalculate when applying updates with the size of the update vector larger than a threshold. Directly applying updates is usually slower than recalculating the whole domtree in this case. This patch fixes an issue which causes JT running slowly on some inputs. In bug 37929, the dominator tree is trying to apply 19,000+ updates several times, which takes several minutes. After this patch, the time used by DT.applyUpdates: | Input | Before (s) | After (s) | Speedup | | the 2nd Reproducer in 37929 | 297 | 0.15 | 1980x | | clang-5.0.0.0.bc | 9.7 | 4.3 | 2.26x | | clang-5.0.0.4.bc | 11.6 | 2.6 | 4.46x | Reviewers: kuhar, brzycki, trentxintong, davide, dmgreen, grosser Reviewed By: kuhar, brzycki Subscribers: kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D53245 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347285 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r342865 | courbet | 2018-09-24 01:39:48 -0700 (Mon, 24 Sep 2018) | 11 lines [llvm-exegesis] Fix PR39021. Summary: The `set` statements was incorrectly reading the value of the local variable and setting the value of the parent variable. Reviewers: tycho, gchatelet, john.brawn Subscribers: mgorny, tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D52343 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347811 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r347431 | rnk | 2018-11-21 14:01:10 -0800 (Wed, 21 Nov 2018) | 12 lines [mingw] Use unmangled name after the $ in the section name GCC does it this way, and we have to be consistent. This includes stdcall and fastcall functions with suffixes. I confirmed that a fastcall function named "foo" ends up in ".text$foo", not ".text$@foo@8". Based on a patch by Andrew Yohn! Fixes PR39218. Differential Revision: https://reviews.llvm.org/D54762 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347931 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r339260 | syzaara | 2018-08-08 08:20:43 -0700 (Wed, 08 Aug 2018) | 13 lines [PowerPC] Improve codegen for vector loads using scalar_to_vector This patch aims to improve the codegen for vector loads involving the scalar_to_vector (load X) sequence. Initially, ld->mv instructions were used for scalar_to_vector (load X), so this patch allows scalar_to_vector (load X) to utilize: LXSD and LXSDX for i64 and f64 LXSIWAX for i32 (sign extension to i64) LXSIWZX for i32 and f64 Committing on behalf of Amy Kwan. Differential Revision: https://reviews.llvm.org/D48950 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@347957 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r344589 | dstenb | 2018-10-16 01:06:48 -0700 (Tue, 16 Oct 2018) | 41 lines
[DebugInfo][LCSSA] Rewrite pre-existing debug values outside loop
Summary:
Extend LCSSA so that debug values outside loops are rewritten to
use the PHI nodes that the pass creates.
This fixes PR39019. In that case, we ran LCSSA on a loop that
was later on vectorized, which left us with something like this:
for.cond.cleanup:
%add.lcssa = phi i32 [ %add, %for.body ], [ %34, %middle.block ]
call void @llvm.dbg.value(metadata i32 %add,
ret i32 %add.lcssa
for.body:
%add =
[...]
br i1 %exitcond, label %for.cond.cleanup, label %for.body
which later resulted in the debug.value becoming undef when
removing the scalar loop (and the location would have probably
been wrong for the vectorized case otherwise).
As we now may need to query the AvailableVals cache more than
once for a basic block, FindAvailableVals() in SSAUpdaterImpl is
changed so that it updates the cache for blocks that we do not
create a PHI node for, regardless of the block's number of
predecessors. The debug value in the attached IR reproducer
would not be properly rewritten without this.
Debug values residing in blocks where we have not inserted any
PHI nodes are currently left as-is by this patch. I'm not sure
what should be done with those uses.
Reviewers: mattd, aprantl, vsk, probinson
Reviewed By: mattd, aprantl
Subscribers: jmorse, gbedwell, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D53130
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348011 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r343369 | vitalybuka | 2018-09-28 19:17:12 -0700 (Fri, 28 Sep 2018) | 1 line [cxx2a] Fix warning triggered by r343285 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348450 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r348181 | lebedevri | 2018-12-03 12:07:58 -0800 (Mon, 03 Dec 2018) | 8 lines [InstCombine] foldICmpWithLowBitMaskedVal(): disable 2 faulty folds. These two folds are invalid for this non-constant pattern when the mask ends up being all-ones: https://rise4fun.com/Alive/9au https://rise4fun.com/Alive/UcQM Fixes https://bugs.llvm.org/show_bug.cgi?id=39861 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348528 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r348461 | lebedevri | 2018-12-06 00:11:20 -0800 (Thu, 06 Dec 2018) | 4 lines [NFC][InstCombine] Add more miscompile tests for foldICmpWithLowBitMaskedVal() We also have to me aware of vector constants. If at least one element is -1, we can't transform. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348535 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r348462 | lebedevri | 2018-12-06 00:14:24 -0800 (Thu, 06 Dec 2018) | 13 lines [InstCombine] foldICmpWithLowBitMaskedVal(): don't miscompile -1 vector elts I was finally able to quantify what i thought was missing in the fix, it was vector constants. If we have a scalar (and %x, -1), it will be instsimplified before we reach this code, but if it is a vector, we may still have a -1 element. Thus, we want to avoid the fold if *at least one* element is -1. Or in other words, ignoring the undef elements, no sign bits should be set. Thus, m_NonNegative(). A follow-up for rL348181 https://bugs.llvm.org/show_bug.cgi?id=39861 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348538 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r340125 | lhames | 2018-08-18 11:38:37 -0700 (Sat, 18 Aug 2018) | 6 lines [RuntimeDyld] Fix a bug in RuntimeDyld::loadObjectImpl that was over-allocating space for common symbols. Patch by Dmitry Sidorov. Thanks Dmitry! Differential revision: https://reviews.llvm.org/D50240 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348555 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r346203 | matze | 2018-11-05 19:15:22 -0800 (Mon, 05 Nov 2018) | 7 lines AArch64: Cleanup CCMP code; NFC Cleanup CCMP pattern matching code in preparation for review/bugfix: - Rename `isConjunctionDisjunctionTree()` to `canEmitConjunction()` (it won't accept arbitrary disjunctions and is really about whether we can transform the subtree into a conjunction that we can emit). - Rename `emitConjunctionDisjunctionTree()` to `emitConjunction()` ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348636 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r348444 | matze | 2018-12-05 17:40:23 -0800 (Wed, 05 Dec 2018) | 15 lines AArch64: Fix invalid CCMP emission The code emitting AND-subtrees used to check whether any of the operands was an OR in order to figure out if the result needs to be negated. However the OR could be hidden in further subtrees and not immediately visible. Change the code so that canEmitConjunction() determines whether the result of the generated subtree needs to be negated. Cleanup emission logic to use this. I also changed the code a bit to make all negation decisions early before we actually emit the subtrees. This fixes http://llvm.org/PR39550 Differential Revision: https://reviews.llvm.org/D54137 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_70@348642 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.