This repository was archived by the owner on Feb 5, 2019. It is now read-only.
Merge LLVM's release_60 branch and a cherry-pick #108
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
------------------------------------------------------------------------ r324772 | thegameg | 2018-02-09 22:47:07 +0100 (Fri, 09 Feb 2018) | 25 lines [X86][MC] Fix assembling rip-relative addressing + immediate displacements In the rare case where the input contains rip-relative addressing with immediate displacements, *and* the instruction ends with an immediate, we encode the instruction in the wrong way: movl $12345678, 0x400(%rdi) // all good, no rip-relative addr movl %eax, 0x400(%rip) // all good, no immediate at the end of the instruction movl $12345678, 0x400(%rip) // fails, encodes address as 0x3fc(%rip) Offset is a label: movl $12345678, foo(%rip) we want to account for the size of the immediate (in this case, $12345678, 4 bytes). Offset is an immediate: movl $12345678, 0x400(%rip) we should not account for the size of the immediate, assuming the immediate offset is what the user wanted. Differential Revision: https://reviews.llvm.org/D43050 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@324875 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324746 | arsenm | 2018-02-09 17:57:48 +0100 (Fri, 09 Feb 2018) | 4 lines AMDGPU: Fix layering issue Move utility function that depends on codegen. Fixes build with r324487 reapplied. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325007 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324449 | chandlerc | 2018-02-06 22:16:24 -0800 (Tue, 06 Feb 2018) | 15 lines [x86/retpoline] Make the external thunk names exactly match the names that happened to end up in GCC. This is really unfortunate, as the names don't have much rhyme or reason to them. Originally in the discussions it seemed fine to rely on aliases to map different names to whatever external thunk code developers wished to use but there are practical problems with that in the kernel it turns out. And since we're discovering this practical problems late and since GCC has already shipped a release with one set of names, we are forced, yet again, to blindly match what is there. Somewhat rushing this patch out for the Linux kernel folks to test and so we can get it patched into our releases. Differential Revision: https://reviews.llvm.org/D42998 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325082 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324645 | dwmw2 | 2018-02-08 12:06:05 -0800 (Thu, 08 Feb 2018) | 5 lines [X86] Support 'V' register operand modifier This allows the register name to be printed without the leading '%'. This can be used for emitting calls to the retpoline thunks from inline asm. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325083 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325049 | rnk | 2018-02-13 12:47:49 -0800 (Tue, 13 Feb 2018) | 17 lines [X86] Use EDI for retpoline when no scratch regs are left Summary: Instead of solving the hard problem of how to pass the callee to the indirect jump thunk without a register, just use a CSR. At a call boundary, there's nothing stopping us from using a CSR to hold the callee as long as we save and restore it in the prologue. Also, add tests for this mregparm=3 case. I wrote execution tests for __llvm_retpoline_push, but they never got committed as lit tests, either because I never rewrote them or because they got lost in merge conflicts. Reviewers: chandlerc, dwmw2 Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D43214 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325084 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325085 | rnk | 2018-02-13 16:24:29 -0800 (Tue, 13 Feb 2018) | 3 lines [X86] Remove dead code from retpoline thunk generation Follow-up to r325049 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325086 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324497 | ctopper | 2018-02-07 19:32:15 +0100 (Wed, 07 Feb 2018) | 1 line [X86] Regenerate test using update_mir_test_checks.py. NFC ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325105 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324576 | ctopper | 2018-02-08 08:45:55 +0100 (Thu, 08 Feb 2018) | 20 lines [X86] Don't emit KTEST instructions unless only the Z flag is being used Summary: KTEST has weird flag behavior. The Z flag is set for all bits in the AND of the k-registers being 0, and the C flag is set for all bits being 1. All other flags are cleared. We currently emit this instruction in EmitTEST and don't check the condition code. This can lead to strange things like using the S flag after a KTEST for a signed compare. The domain reassignment pass can also transform TEST instructions into KTEST and is not protected against the flag usage either. For now I've disabled this part of the domain reassignment pass. I tried to comment out the checks in the mir test so that we could recover them later, but I couldn't figure out how to get that to work. This patch moves the KTEST handling into LowerSETCC and now creates a ktest+x86setcc. I've chosen this approach because I'd like to add support for the C flag for all ones in a followup patch. To do that requires that I can rewrite the condition code going in the x86setcc to be different than the original SETCC condition code. This fixes PR36182. I'll file a PR to fix domain reassignment once this goes in. Should this be merged to 6.0? Reviewers: spatel, guyblank, RKSimon, zvi Reviewed By: guyblank Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42770 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325106 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324962 | kuhar | 2018-02-13 00:37:27 +0100 (Tue, 13 Feb 2018) | 16 lines [Dominators] Always recalculate postdominators when update yields different roots Summary: This patch makes postdominators always recalculate the tree when an update causes to change the tree roots. As @dmgreen noticed in [[ https://reviews.llvm.org/D41298 | D41298 ]], the previous implementation was not conservative enough and it was possible to end up with a PostDomTree that was different than a freshly computed one. The patch also compares postdominators with a freshly computed tree at the end of full verification to make sure we don't hit similar issues in the future. This should (ideally) be also backported to 6.0 before the release, although I don't have any reports of this causing an observable error. It should be safe to do it even if it's late in the release, as the change only makes the current behavior more conservative. Reviewers: dmgreen, dberlin, davide, brzycki, grosser Reviewed By: brzycki, grosser Subscribers: llvm-commits, dmgreen Differential Revision: https://reviews.llvm.org/D43140 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325108 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325111 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325112 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325139 | rafael | 2018-02-14 17:34:27 +0100 (Wed, 14 Feb 2018) | 12 lines Store defined macros in MCContext. So that macros defined in inline assembly blocks are available to the whole file. This provides a consistent behavior with other assembly directives, since equations for example are already preserved between inline assembly blocks. PR: 36110 Patch by Roger! ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325330 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324353 | mareko | 2018-02-06 16:17:55 +0100 (Tue, 06 Feb 2018) | 5 lines AMDGPU: Fix S_BUFFER_LOAD_DWORD_SGPR moveToVALU Author: Bas Nieuwenhuizen https://reviews.llvm.org/D42881 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325497 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325168 | rksimon | 2018-02-14 21:43:47 +0100 (Wed, 14 Feb 2018) | 1 line Removed superfluous semicolon to fix -Wpedantic gcc warning. NFCI. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325498 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325148 | ctopper | 2018-02-14 19:08:33 +0100 (Wed, 14 Feb 2018) | 7 lines [InstCombine] Don't fold select(C, Z, binop(select(C, X, Y), W)) -> select(C, Z, binop(Y, W)) if the binop is rem or div. The select may have been preventing a division by zero or INT_MIN/-1 so removing it might not be safe. Fixes PR36362. Differential Revision: https://reviews.llvm.org/D43276 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325501 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324916 | junbuml | 2018-02-12 18:56:55 +0100 (Mon, 12 Feb 2018) | 7 lines [LICM] update BlockColors after splitting predecessors Update BlockColors after splitting predecessors. Do not allow splitting EHPad for sinking when the BlockColors is not empty, so we can simply assign predecessor's color to the new block. Fixes PR36184 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325507 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324195 | mcrosier | 2018-02-04 16:42:24 +0100 (Sun, 04 Feb 2018) | 12 lines [LV] Use Demanded Bits and ValueTracking for reduction type-shrinking The type-shrinking logic in reduction detection, although narrow in scope, is also rather ad-hoc, which has led to bugs (e.g., PR35734). This patch modifies the approach to rely on the demanded bits and value tracking analyses, if available. We currently perform type-shrinking separately for reductions and other instructions in the loop. Long-term, we should probably think about computing minimal bit widths in a more complete way for the loops we want to vectorize. PR35734 Differential Revision: https://reviews.llvm.org/D42309 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325508 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r324110 | aemerson | 2018-02-02 19:03:30 +0100 (Fri, 02 Feb 2018) | 3 lines [AArch64][GlobalISel] Use getRegClassForTypeOnBank() in selectCopy. Differential Revision: https://reviews.llvm.org/D42832 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325584 91177308-0d34-0410-b5e6-96231b3b80d8
(I had to re-generate the test and manually update to handle the r323922 MIR physical register sigil. ------------------------------------------------------------------------ r325463 | aemerson | 2018-02-18 18:10:49 +0100 (Sun, 18 Feb 2018) | 8 lines [AArch64][GlobalISel] Fix an assert fail/miscompile when fp16 types are copied to gpr register banks. PR36345. rdar://36478867 Differential Revision: https://reviews.llvm.org/D43310 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325586 91177308-0d34-0410-b5e6-96231b3b80d8
I couldn't get fp16-copy-gpr.mir to pass after merging so I removed it until aemerson; the other test I re-generated and it seems to work. ------------------------------------------------------------------------ r325550 | aemerson | 2018-02-20 06:11:57 +0100 (Tue, 20 Feb 2018) | 7 lines [AArch64][GlobalISel] When copying from a gpr32 to an fpr16 reg, convert to fpr32 first. This is a follow on commit to r[x] where we fix the other direction of copy. For this case, after converting the source from gpr32 -> fpr32, we use a subregister copy, which is essentially what EXTRACT_SUBREG does in SDAG land. https://reviews.llvm.org/D43444 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325591 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325525 | steven_wu | 2018-02-19 20:22:28 +0100 (Mon, 19 Feb 2018) | 13 lines bitcode support change for fast flags compatibility Summary: The discussion and as per need, each vendor needs a way to keep the old fast flags and the new fast flags in the auto upgrade path of the IR upgrader. This revision addresses that issue. Patched by Michael Berg Reviewers: qcolombet, hans, steven_wu Reviewed By: qcolombet, steven_wu Subscribers: dexonsmith, vsk, mehdi_amini, andrewrk, MatzeB, wristow, spatel Differential Revision: https://reviews.llvm.org/D43253 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325592 91177308-0d34-0410-b5e6-96231b3b80d8
These are needed for operations on fp16 types in a later patch. This also re-instates the test/CodeGen/AArch64/GlobalISel/fp16-copy-gpr.mir test that was deleted which depended on this patch. (See PR36345.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325669 91177308-0d34-0410-b5e6-96231b3b80d8
By Kamil Rytarowski! git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325670 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325654 | ctopper | 2018-02-21 01:15:48 +0100 (Wed, 21 Feb 2018) | 10 lines [X86] Disable CLWB for Cannon Lake Cannon Lake does not support CLWB, therefore it does not include all features listed under SKX anymore. Instead, enumerate all SKX features with the exception of CLWB. Patch by Gabor Buella Differential Revision: https://reviews.llvm.org/D43380 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325671 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325709 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325739 | nemanjai | 2018-02-22 04:02:41 +0100 (Thu, 22 Feb 2018) | 9 lines [PowerPC] Do not produce invalid CTR loop with an FRem An FRem instruction inside a loop should prevent the loop from being converted into a CTR loop since this is not an operation that is legal on any PPC subtarget. This will always be a call to a library function which means the loop will be invalid if this instruction is in the body. Fixes PR36292. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325767 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325687 | sbaranga | 2018-02-21 16:20:32 +0100 (Wed, 21 Feb 2018) | 8 lines [SCEV] Temporarily disable loop versioning for the purpose of turning SCEVUnknowns of PHIs into AddRecExprs. This feature is now hidden behind the -scev-version-unknown flag. Fixes PR36032 and PR35432. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325773 91177308-0d34-0410-b5e6-96231b3b80d8
By Sanjay Patel! git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325776 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325786 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewers: atanasyan, arichardson, petarj, smaksimovic, abeserminji Differential Revision: https://reviews.llvm.org/D43573 git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325876 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325894 | hans | 2018-02-23 13:20:26 +0100 (Fri, 23 Feb 2018) | 1 line llvm-config: Add advapi32 to --system-libs on Windows (PR36372) ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325895 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@325932 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326075 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r325946 | echristo | 2018-02-23 21:12:24 +0100 (Fri, 23 Feb 2018) | 15 lines Because of CVE-2018-6574, some compiler options and linker options are restricted to prevent arbitrary code execution. golang/go#23672 By this change, building a Go code with LLVM Go bindings causes a compilation error as follows. go build llvm.org/llvm/bindings/go/llvm: invalid flag in #cgo LDFLAGS: -Wl,-headerpad_max_install_names llvm-go tool generates cgo LDFLAGS directive from `llvm-config --ldflags` and it contains -Wl,option options. But -Wl,option is banned by default. To avoid this problem, we need to set $CGO_LDFLAGS_ALLOW environment variable to notify a compiler that the flags should be allowed. $ export CGO_LDFLAGS_ALLOW='-Wl,(-search_paths_first|-headerpad_max_install_names)' By default for go 1.10 and go 1.9.5 these options should appear in the accepted set of options, however, if you're running into the error it's useful to have this documented. Patch by Ryuichi Hayashida ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326076 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326184 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326186 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r326393 | ctopper | 2018-03-01 01:08:38 +0100 (Thu, 01 Mar 2018) | 5 lines [X86] Make sure we don't combine (fneg (fma X, Y, Z)) to a target specific node when there are no FMA instructions. This would cause a 'cannot select' error at isel when we should have emitted a lib call and an xor. Fixes PR36553. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326423 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326539 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@326549 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is a workaround for pr36417 https://bugs.llvm.org/show_bug.cgi?id=36417 LiveDebugVariables will now verify that the DBG_VALUE instructions are sane (prior to register allocation) by asking LIS if a virtual register used in the DBG_VALUE is live (or dead def) in the slot index before the DBG_VALUE. If it isn't sane the DBG_VALUE is discarded. One pass that was identified as introducing non-sane DBG_VALUE instructtons, when analysing pr36417, was the DAG->DAG Instruction Selection. It sometimes inserts DBG_VALUE instructions referring to a virtual register that is defined later in the same basic block. So it is a use before def kind of problem. The DBG_VALUE is typically inserted in the beginning of a basic block when this happens. The problem can be seen in the test case test/DebugInfo/X86/dbg-value-inlined-parameter.ll Reviewers: aprantl, rnk, probinson Reviewed By: aprantl Subscribers: vsk, davide, alexcrichton, Ka-Ka, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D43956 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326769 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This PR merges LLVM's release_60 branch and cherry-picks https://reviews.llvm.org/D43956 to deal with rust-lang/rust#48226